Да, простит меня уважаемый Леонид, которые в теме Перевод с UML высказал такую мысль:

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

Леонид, не могли бы развернуть свою мысль? Высказав концепцию правильного подхода к труду аналитика ИС, и чем плох мышления в категориях сценариев?

Спасибо

Леонид, не могли бы развернуть свою мысль? Высказав концепцию правильного подхода к труду аналитика ИС, и чем плох мышления в категориях сценариев?

Спасибо

Конечно. Мысли свои, на абсолютную истину не претендующие.

Любой аналитик - финансовый, военный, кредитный и т.д., включая наших собратьев по цеху, занимается ровно одним: преобразует данные в информацию.
Если чуть расширить - различными способами добывает данные, затем их обрабатывает (анализ + синтез + внутричерепная магия), а полученную в результате информацию оформляет и передает потребителю. В идеальном случае, информация принимает форму выводов и рекомендаций для принятия соответствующих решений.

В случае бизнес/системного анализа, информация в норме принимает форму требований к системе (например, ТЗ), а "выводы и рекомендации" - решений технорабочего проекта (или спецификаций). Важно, что именно решений, а не постановки. Это, на мой взгляд, наивысший возможный вклад аналитика в процесс.

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

Получается, что аналитик, результат работы которого - собранные и как-то формализованные данные, по сути даже не начал их обрабатывать, не говоря уже о получении информации и превращении ее в рекомендации. То есть, находится в самом начале цепочки создания ценности. Добавленная стоимость его "продукта" - мизерная по сравнению с той, которая может быть создана при прохождении всего "маршрута". Навыки, потребные для получения такого рода результатов примитивные: ни собственно анализ, ни синтез практически не применяются.

Именно поэтому я считаю такую организацию труда, при которой сценарии являются вершиной аналитической мысли, убогой (с позиции утилизации аналитических "мощностей"). А аналитиков, расходующих свой ограниченный трудовой ресурс на такого рода работу, вредящими себе. Собственно, они даже аналитикой не занимаются, в контексте определения из первых строк поста.

Я не отказываю в праве на существование таким процессам. Иногда они целесообразны и оправданы. Но для хорошего аналитика, или желающего таковым стать, они губительны. ("В совершенстве владеете иностранным языком? Отлично, будете наклеивать марки на конверты!")
И да, я трудился некоторое время аналитиком-сценаристом. Опыт из первых рук.

Мне кажется, что наличие сценариев не противоречит наличию решений. В итоге потребителями выводов и рекомендаций являются владельцы процессов, потребителями сценариев - среда разработки (возможно, не только). Отсутствие сценариев, по моему опыту, весьма негативно влияет на качество итогового продукта.
Насколько я понимаю, Вы пытаетесь сказать, что сценарии не могут быть единственным результатом работы бизнес\системного аналитика, а их количество\полнота\качество не являются в итоге критерием качественно выполненной работы аналитика. Поправьте, пожалуйста, если я не права

В случае бизнес/системного анализа, информация в норме принимает форму требований к системе (например, ТЗ), а "выводы и рекомендации" - решений технорабочего проекта (или спецификаций). Важно, что именно решений, а не постановки. Это, на мой взгляд, наивысший возможный вклад аналитика в процесс.

Наивысший возможный вклад аналитика, это если он сам соберёт, задокументирует требования, сформирует архитектуру и дизайн системы, закодирует, выполнит сборку, развернёт систему, протестирует, а потом ещё и поддержку осуществлять будет. В жизни, насколько я представляю себе, аналитик будет заниматься только той частью, которой ему поручат заниматься. "Решения" могут быть разные: аналитические, архитектурные, дизайнерские, реализационные. Не думаю что в крупных проектах рационально возлагать ответственность за все решения на аналитика. В части проектов аналитику могут поручить только собрать, задокументировать требования и управлять изменениями требований, но не касаться преобразования (принятия решений) требований в модель анализа.

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

В случае если спецификации ВИ написаны качественно, то сценарии будут не разрозненными и неполными, а хорошо структурированными и полными.

Получается, что аналитик, результат работы которого - собранные и как-то формализованные данные, по сути даже не начал их обрабатывать, не говоря уже о получении информации и превращении ее в рекомендации. То есть, находится в самом начале цепочки создания ценности. Добавленная стоимость его "продукта" - мизерная по сравнению с той, которая может быть создана при прохождении всего "маршрута". Навыки, потребные для получения такого рода результатов примитивные: ни собственно анализ, ни синтез практически не применяются.

Мизерность добавленной стоимости и примитивность навыков... Очень спорное мнение. Почему при мизерной добавленной стоимости работодатели согласны платить такие высокие зарплаты аналитикам? И есть ли у Вас данные о том, какое количество выпускников общеобразовательных школ обладают всеми необходимыми компетенциями для качественного сбора и документирования требований к ПО?

Именно поэтому я считаю такую организацию труда, при которой сценарии являются вершиной аналитической мысли, убогой (с позиции утилизации аналитических "мощностей"). А аналитиков, расходующих свой ограниченный трудовой ресурс на такого рода работу, вредящими себе. Собственно, они даже аналитикой не занимаются, в контексте определения из первых строк поста.
двусмысленности, неполноты, и несогласованности

Что по Вашему должно являться "вершиной аналитической мысли" вместо ВИ чтобы аналитики не "вредили себе"? Определения могут быть разными и под аналитикой также может пониматься устранение несогласованности, дублирования, противоречий, контроль соответствия бизнес-проблемам и потребностям.

Я не отказываю в праве на существование таким процессам. Иногда они целесообразны и оправданы. Но для хорошего аналитика, или желающего таковым стать, они губительны. ("В совершенстве владеете иностранным языком? Отлично, будете наклеивать марки на конверты!")
И да, я трудился некоторое время аналитиком-сценаристом. Опыт из первых рук.

В каких случаях, по Вашему, такие процессы могут быть целесообразны и оправданы?

Мне кажется, что наличие сценариев не противоречит наличию решений.

Не противоречит.

В итоге потребителями выводов и рекомендаций являются владельцы процессов, потребителями сценариев - среда разработки (возможно, не только).

Выводы и рекомендации могут быть даны в спеке, например, в виде макета экранной формы. Кто будет потребителем?

Насколько я понимаю, Вы пытаетесь сказать, что сценарии не могут быть единственным результатом работы бизнес\системного аналитика,

Я высказался о производственных процессах, в которых основным результатом труда аналитика являются сценарии. Если бы таковых не было, высказываться было бы не о чем. Если бы таковые не применялись все шире, высказываться было бы незачем.

а их количество\полнота\качество не являются в итоге критерием качественно выполненной работы аналитика.

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

Я высказался о производственных процессах, в которых основным результатом труда аналитика являются сценарии. Если бы таковых не было, высказываться было бы не о чем. Если бы таковые не применялись все шире, высказываться было бы незачем.

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

Леонид, спасибо за Ваше мнение.

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

В целом понятна Ваша "нелюбовь" к сценариям. Но не очень понятна правильная альтернатива. Не могли бы Вы очертить, именно, этот подход? 

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

Гриша, а на чем зиждется такое утверждение. Очень интересно.

... сформирует архитектуру и дизайн системы, закодирует, выполнит сборку, развернёт систему, протестирует, а потом ещё и поддержку осуществлять будет.

Считаете, это является частью работы аналитика?

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

Так и есть. Плюс/минут то, что он сам под себя загребет.

"Решения" могут быть разные: аналитические, архитектурные, дизайнерские, реализационные. Не думаю что в крупных проектах рационально возлагать ответственность за все решения на аналитика.

Вероятно. Какое отношение это имеет к тому, что я сказал?

В части проектов аналитику могут поручить только собрать, задокументировать требования и управлять изменениями требований, но не касаться преобразования (принятия решений) требований в модель анализа.

Лично Вы готовы заниматься этим до пенсии? Вы считаете, что эти занятия приведут Вас к вершинам профессии?

В случае если спецификации ВИ написаны качественно, то сценарии будут не разрозненными и неполными, а хорошо структурированными и полными.

Главное, ни в коем случае не добавлять туда новые сценарии.

Почему при мизерной добавленной стоимости работодатели согласны платить такие высокие зарплаты аналитикам?

Не следует ли спросить об этом работодателей? Хотя я бы не стал. Задумаются.
По моему опыту, работодатели сами слабо представляют, что такое аналитик и как его "готовить".

И есть ли у Вас данные о том, какое количество выпускников общеобразовательных школ обладают всеми необходимыми компетенциями для качественного сбора и документирования требований к ПО?

Нет. А Вы с какой целью интересуетесь?

Что по Вашему должно являться "вершиной аналитической мысли" вместо ВИ чтобы аналитики не "вредили себе"?

Написано в первом посте темы.

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

Не возражаю. Я даже готов к тому, что аналитикой будет называться процесс проведения общего анализа мочи. Какое отношение это имеет к тому, что я писал в первом посте?

В каких случаях, по Вашему, такие процессы могут быть целесообразны и оправданы?

В ситуациях, когда окружающее определено настолько, что информация для принятия решений (выполнения работ) не требуется или требуется в последнюю очередь.

Гриша, а на чем зиждется такое утверждение. Очень интересно.

Присоединяюсь.

Мы все поняли, чем плохи сценарии.

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

Правда, прецедент(он же вариант использования, он же способ применения) является не просто сценарием, а коллекцией (совокупностью) сценариев.

На практике я больше сталкивался с наборами разрозненных ВИ. И хорошо еще, если исключения в них были хоть как-то отработаны.

Но не очень понятна правильная альтернатива. Не могли бы Вы очертить, именно, этот подход?

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

Гриша, а на чем зиждется такое утверждение. Очень интересно.

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

Для веб-сайтов сценарный подход тоже оказался неприменим. User Stories возникли не случайно. Это откат назад по сравнению с Use Cases: мы отказывается описывать конкретные сценарии взаимодействия пользователя с системой, оставляя только его цель.

Я буквально вчера отчасти об этом в своём курсе рассказывал, и только что выложил ту часть вебинара, где немного об этом говорю. В частности, почему Вигерс в качестве основного документа требований второго уровня выделяет спецификацию вариантов использования: https://vimeo.com/88255472

Фрагмент получился довольно длинным (40 минут), а собственно рассуждения на эту тему начинаются с отметки 21:58. Хотя я его пересмотрел и обнаружил, что в моих примерах тоже постоянно фигурирует понятие сценария. Но я его понимаю более широко, чем "заданный порядок взаимодействия".

Ага, спасибо Гриша. Я понял проблему ВИ, которую ты озвучил, которой правда столько же лет, сколько я знаю, что такое ВИ (не менее 10 лет).

Я соглашусь на 100%, что ВИ не единственный и не исключительный способ описания функциональных требований. Я только не пойму почему это стало вдруг так актуально? Что разве 10 лет назад мы пытались описать работу с Excel через ВИ?

Что значит описание веб-сайтов? Это что, какой-то специфический тип приложения?

Может проблема в том, что мы просто наблюдаем (среди студентов, начинающих аналитиков) преобладание use case driven development? Ну, и это скажем немного раздражает?

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

Леонид, спасибо. Можно, хотя бы кратко, весь цикл инфоработы и его результат?

Считаете, это является частью работы аналитика?

Я имел ввиду другое. Степень вклада аналитика (глубина проработки) в разных проектах разная. Поэтому я считаю некорректным устанавливать границу, на которой находится "наивысший возможный вклад аналитика".

Вероятно. Какое отношение это имеет к тому, что я сказал?

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

Лично Вы готовы заниматься этим до пенсии? Вы считаете, что эти занятия приведут Вас к вершинам профессии?

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

Главное, ни в коем случае не добавлять туда новые сценарии.

Чем это грозит?

Не следует ли спросить об этом работодателей? Хотя я бы не стал. Задумаются.
По моему опыту, работодатели сами слабо представляют, что такое аналитик и как его "готовить".

Работодатели бывают разные. Даже те, которые "слабо представляют" судя по всему осознают что с аналитиками лучше чем без них.

Нет. А Вы с какой целью интересуетесь?

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

Не возражаю. Я даже готов к тому, что аналитикой будет называться процесс проведения общего анализа мочи. Какое отношение это имеет к тому, что я писал в первом посте?

Я бы не стал ограничиваться Вашим определением аналитики и на основании этого делать вывод что аналитики не занимаются аналитической работой.

В ситуациях, когда окружающее определено настолько, что информация для принятия решений (выполнения работ) не требуется или требуется в последнюю очередь.

В моем представлении как раз наоборот. ВИ нужны для того чтобы согласовать общее понимание неопределенного окружения.