Тренды в инженерии требований и кому они интересны
После вчерашнего доклада "Тренды в инженерии требований" (слайды и видео: http://incose-ru.livejournal.com/53170.html) один из участников заседания прислал мне письмо о потенциальных стейкхолдерах, которые могли бы быть заинтересованными в тех новинках инженерии требований, о которых я говорил в докладе. Сам он не смог сообразить, кто бы это мог быть -- ибо по его опыту работы в крупной авиастроительной российской корпорации "(несмотря на то, что об управлении требованиями постоянно говорят) могу сказать, что перед управлением требованиями (или вообще любой системноинженерной дисциплиной) заинтересованные стороны говорят о проблемах, которые решаются внедрением элементарного планирования и контроля (то есть, то,что можно было бы исправить инженерией требований, вовсе не в первом приоритете)".
У меня тут сразу несколько ответов:
1. Да, когда корабль тонет, если в одной из его кают срочно и серьёзно займутся инженерией требований, обитателям этой конкретной каюты может не свезти точно так же, как и обитателям любых соседних кают, в которых вместо работы выбирают sex, drugs and rock'n'roll. Имкрыш настанет, несмотря на импортзамещение (точнее, ровно поэтому).
2. Если посмотреть содержательно на новинки инженерии требований, то заниматься ими нужно только, если действительно хочется победить в международной конкуренции. Если хочется огромные проекты делать дешевле и быстрее. И первое, что в этих новинках -- там слошные исследования и разработки, нет ничего отлаженного, это фронтир, bleeding edge. Про долю затрат на исследования и разработки в российских инженерных фирмах я даже говорить не хочу. Нет таких стейкхолдеров, которым нужны исследования и разработки по методологии инженерии, и не только инженерии требований.
3. Инженерия требований -- это часть системной инженерии. На отечественных предприятиях системная инженерия неизвестна. Заинтересованных в каком-то кусочке неизвестного нет. Стейкхолдеров, у которых есть интерес к трендам в неизвестном -- массово таких нет. Единственное что, так это IT-фирмы. Им инженерия требований известна как отдельная дисциплина, часть их собственной дисциплины (а не как часть системной инженерии). Но IT-фирмы самолёты не выпускают. Зато в них вполне могут найтись правильные стейкхолдеры (прошлого поколения -- "аналитики". Я как раз в докладе говорю, что жизнь изменилась, и они ответственны теперь отнюдь не только за выявление и анализ требований -- нет, у них ещё и решение всех проблем со стейкхолдерами, это активная деятельность и вмешательство в жизнь, а не "аналитическая работа пониманию и выдаче советов"). Вопрос, насколько крупны эти IT-фирмы, чтобы позволить себе исследования и разработки на фронтире инженерии требований?
4. Нашим клиентам мы сначала всегда предлагаем наладить управление конфигурацией и изменениями. Они спрашивают в ответ: "Что это такое?". А ведь это и есть то самое "элементарное планирование и контроль" из вопроса. Кстати, в инженерии требований то же самое: сначала управление требованиями, а потом уж их инженерия. Ибо если в суматохе самое распрекрасное требование будет открыто, но потом потеряно в обычной суматохе и текучке, толку от этого распрекрасного требования -- ноль. Не задокументировано, не учтено -- значит нету. К инженерии требований это всё тоже относится. Требование -- это приписанное к части системы утверждение (assertion). Контрольная точка -- это достижение этого требования к какому-то моменту. Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.
5. Можно предположить, что заинтересованные в новинках инженерии требований стейкхолдеры есть -- но они просто об этих новинках не знают. Да, теоретически они есть. А практически -- это похоже на сказки про царя, который просто не знает об ужасах, которые творятся в его царстве. В век интернета и почти поголовного владения английским в эту сказку трудно поверить. Но теоретически такая возможность есть, так что пусть этот пункт тут побудет.
6. Тем не менее, бывают ситуации, в которых у отдельных людей просыпается личный (обусловленный биографией, человеческими качествами, любопытством и т.д.) интерес к инженерии требований. Иногда у таких людей бывает даже достаточно полномочий, чтобы реализовать проект по постановке практики (скажем, наладить моделирование какого-то вида требований с использованием Modelica или даже Julia, как у заморских авиаторов в примере из доклада). Иногда коллеги-начальники даже этот проект не срывают по совокупности причин. Иногда вместо дела получается пара-тройка учебных курсов (хотя реализовать полученные знания на практике всё равно не получится -- по той же "совокупности причин"), иногда этот личный интерес реализуется вообще вне какой-то инженерной организации, как личное хобби. В любом случае, тут речь про людей, а не про стейкхолдеров. С людьми всё в порядке, с людьми я и работаю. Так что для таких людей я и сделал доклад, и выложил слайды и видео -- http://incose-ru.livejournal.com/53170.html
* * *
Мне было приятно делать этот доклад: то, о чём я догадался ещё несколько лет назад, наконец-то начало закрепляться в стандартах и появляться в моделерах. Так что в некотором роде этот доклад ещё и хвастовство по поводу собственной прозорливости.
Сами тренды тут прописывать не буду, их оказалось неожиданно много, изменений буквально за пару лет в инженерии требований произошло много каких. Если интересно, можете пролистать слайды (там картинок мало, но зато есть какие-то тезисы и некоторое количество ссылок на литературу) и послушать мои комментарии на видео.
У меня тут сразу несколько ответов:
1. Да, когда корабль тонет, если в одной из его кают срочно и серьёзно займутся инженерией требований, обитателям этой конкретной каюты может не свезти точно так же, как и обитателям любых соседних кают, в которых вместо работы выбирают sex, drugs and rock'n'roll. Имкрыш настанет, несмотря на импортзамещение (точнее, ровно поэтому).
2. Если посмотреть содержательно на новинки инженерии требований, то заниматься ими нужно только, если действительно хочется победить в международной конкуренции. Если хочется огромные проекты делать дешевле и быстрее. И первое, что в этих новинках -- там слошные исследования и разработки, нет ничего отлаженного, это фронтир, bleeding edge. Про долю затрат на исследования и разработки в российских инженерных фирмах я даже говорить не хочу. Нет таких стейкхолдеров, которым нужны исследования и разработки по методологии инженерии, и не только инженерии требований.
3. Инженерия требований -- это часть системной инженерии. На отечественных предприятиях системная инженерия неизвестна. Заинтересованных в каком-то кусочке неизвестного нет. Стейкхолдеров, у которых есть интерес к трендам в неизвестном -- массово таких нет. Единственное что, так это IT-фирмы. Им инженерия требований известна как отдельная дисциплина, часть их собственной дисциплины (а не как часть системной инженерии). Но IT-фирмы самолёты не выпускают. Зато в них вполне могут найтись правильные стейкхолдеры (прошлого поколения -- "аналитики". Я как раз в докладе говорю, что жизнь изменилась, и они ответственны теперь отнюдь не только за выявление и анализ требований -- нет, у них ещё и решение всех проблем со стейкхолдерами, это активная деятельность и вмешательство в жизнь, а не "аналитическая работа пониманию и выдаче советов"). Вопрос, насколько крупны эти IT-фирмы, чтобы позволить себе исследования и разработки на фронтире инженерии требований?
4. Нашим клиентам мы сначала всегда предлагаем наладить управление конфигурацией и изменениями. Они спрашивают в ответ: "Что это такое?". А ведь это и есть то самое "элементарное планирование и контроль" из вопроса. Кстати, в инженерии требований то же самое: сначала управление требованиями, а потом уж их инженерия. Ибо если в суматохе самое распрекрасное требование будет открыто, но потом потеряно в обычной суматохе и текучке, толку от этого распрекрасного требования -- ноль. Не задокументировано, не учтено -- значит нету. К инженерии требований это всё тоже относится. Требование -- это приписанное к части системы утверждение (assertion). Контрольная точка -- это достижение этого требования к какому-то моменту. Если нет учёта частей системы, то и приписывания к ним утверждений нельзя сделать. Если нет контрольных точек, то выполнение требований гарантировать нельзя. Остальное всё потом: никакое моделирование бардака или переговоры по поводу бардака не помогут.
5. Можно предположить, что заинтересованные в новинках инженерии требований стейкхолдеры есть -- но они просто об этих новинках не знают. Да, теоретически они есть. А практически -- это похоже на сказки про царя, который просто не знает об ужасах, которые творятся в его царстве. В век интернета и почти поголовного владения английским в эту сказку трудно поверить. Но теоретически такая возможность есть, так что пусть этот пункт тут побудет.
6. Тем не менее, бывают ситуации, в которых у отдельных людей просыпается личный (обусловленный биографией, человеческими качествами, любопытством и т.д.) интерес к инженерии требований. Иногда у таких людей бывает даже достаточно полномочий, чтобы реализовать проект по постановке практики (скажем, наладить моделирование какого-то вида требований с использованием Modelica или даже Julia, как у заморских авиаторов в примере из доклада). Иногда коллеги-начальники даже этот проект не срывают по совокупности причин. Иногда вместо дела получается пара-тройка учебных курсов (хотя реализовать полученные знания на практике всё равно не получится -- по той же "совокупности причин"), иногда этот личный интерес реализуется вообще вне какой-то инженерной организации, как личное хобби. В любом случае, тут речь про людей, а не про стейкхолдеров. С людьми всё в порядке, с людьми я и работаю. Так что для таких людей я и сделал доклад, и выложил слайды и видео -- http://incose-ru.livejournal.com/53170.html
* * *
Мне было приятно делать этот доклад: то, о чём я догадался ещё несколько лет назад, наконец-то начало закрепляться в стандартах и появляться в моделерах. Так что в некотором роде этот доклад ещё и хвастовство по поводу собственной прозорливости.
Сами тренды тут прописывать не буду, их оказалось неожиданно много, изменений буквально за пару лет в инженерии требований произошло много каких. Если интересно, можете пролистать слайды (там картинок мало, но зато есть какие-то тезисы и некоторое количество ссылок на литературу) и послушать мои комментарии на видео.