Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Galogen от 04 Марта 2014, 21:42:27
-
Да, простит меня уважаемый Леонид, которые в теме Перевод с UML (http://www.uml2.ru/forum/index.php?topic=6141.msg37075#msg37075) высказал такую мысль:
Да и мыслить в категориях сценариев (с их описанием и изображением) мне и непривычно, и неприятно. Я считаю такой подход к труду аналитика информационных систем убогим, а для практикующего аналитика еще и вредным.
Леонид, не могли бы развернуть свою мысль? Высказав концепцию правильного подхода к труду аналитика ИС, и чем плох мышления в категориях сценариев?
Спасибо
-
Леонид, не могли бы развернуть свою мысль? Высказав концепцию правильного подхода к труду аналитика ИС, и чем плох мышления в категориях сценариев?
Спасибо
Конечно. Мысли свои, на абсолютную истину не претендующие.
Любой аналитик - финансовый, военный, кредитный и т.д., включая наших собратьев по цеху, занимается ровно одним: преобразует данные в информацию.
Если чуть расширить - различными способами добывает данные, затем их обрабатывает (анализ + синтез + внутричерепная магия), а полученную в результате информацию оформляет и передает потребителю. В идеальном случае, информация принимает форму выводов и рекомендаций для принятия соответствующих решений.
В случае бизнес/системного анализа, информация в норме принимает форму требований к системе (например, ТЗ), а "выводы и рекомендации" - решений технорабочего проекта (или спецификаций). Важно, что именно решений, а не постановки. Это, на мой взгляд, наивысший возможный вклад аналитика в процесс.
Теперь к сценариям. Сценарии - своего рода формализованные представления об ожидаемом поведении системы в частных случаях. То есть, по сути своей - разрозненные и неполные данные для дальнейшей обработки с целью получения информации о том, какими возможностями должна обладать система, дабы выполнять поставленные задачи (в т.ч. свой набор сценариев).
Получается, что аналитик, результат работы которого - собранные и как-то формализованные данные, по сути даже не начал их обрабатывать, не говоря уже о получении информации и превращении ее в рекомендации. То есть, находится в самом начале цепочки создания ценности. Добавленная стоимость его "продукта" - мизерная по сравнению с той, которая может быть создана при прохождении всего "маршрута". Навыки, потребные для получения такого рода результатов примитивные: ни собственно анализ, ни синтез практически не применяются.
Именно поэтому я считаю такую организацию труда, при которой сценарии являются вершиной аналитической мысли, убогой (с позиции утилизации аналитических "мощностей"). А аналитиков, расходующих свой ограниченный трудовой ресурс на такого рода работу, вредящими себе. Собственно, они даже аналитикой не занимаются, в контексте определения из первых строк поста.
Я не отказываю в праве на существование таким процессам. Иногда они целесообразны и оправданы. Но для хорошего аналитика, или желающего таковым стать, они губительны. ("В совершенстве владеете иностранным языком? Отлично, будете наклеивать марки на конверты!")
И да, я трудился некоторое время аналитиком-сценаристом. Опыт из первых рук.
-
Мне кажется, что наличие сценариев не противоречит наличию решений. В итоге потребителями выводов и рекомендаций являются владельцы процессов, потребителями сценариев - среда разработки (возможно, не только). Отсутствие сценариев, по моему опыту, весьма негативно влияет на качество итогового продукта.
Насколько я понимаю, Вы пытаетесь сказать, что сценарии не могут быть единственным результатом работы бизнес\системного аналитика, а их количество\полнота\качество не являются в итоге критерием качественно выполненной работы аналитика. Поправьте, пожалуйста, если я не права :)
-
В случае бизнес/системного анализа, информация в норме принимает форму требований к системе (например, ТЗ), а "выводы и рекомендации" - решений технорабочего проекта (или спецификаций). Важно, что именно решений, а не постановки. Это, на мой взгляд, наивысший возможный вклад аналитика в процесс.
Наивысший возможный вклад аналитика, это если он сам соберёт, задокументирует требования, сформирует архитектуру и дизайн системы, закодирует, выполнит сборку, развернёт систему, протестирует, а потом ещё и поддержку осуществлять будет. В жизни, насколько я представляю себе, аналитик будет заниматься только той частью, которой ему поручат заниматься. "Решения" могут быть разные: аналитические, архитектурные, дизайнерские, реализационные. Не думаю что в крупных проектах рационально возлагать ответственность за все решения на аналитика. В части проектов аналитику могут поручить только собрать, задокументировать требования и управлять изменениями требований, но не касаться преобразования (принятия решений) требований в модель анализа.
Теперь к сценариям. Сценарии - своего рода формализованные представления об ожидаемом поведении системы в частных случаях. То есть, по сути своей - разрозненные и неполные данные для дальнейшей обработки с целью получения информации о том, какими возможностями должна обладать система, дабы выполнять поставленные задачи (в т.ч. свой набор сценариев).
В случае если спецификации ВИ написаны качественно, то сценарии будут не разрозненными и неполными, а хорошо структурированными и полными.
Получается, что аналитик, результат работы которого - собранные и как-то формализованные данные, по сути даже не начал их обрабатывать, не говоря уже о получении информации и превращении ее в рекомендации. То есть, находится в самом начале цепочки создания ценности. Добавленная стоимость его "продукта" - мизерная по сравнению с той, которая может быть создана при прохождении всего "маршрута". Навыки, потребные для получения такого рода результатов примитивные: ни собственно анализ, ни синтез практически не применяются.
Мизерность добавленной стоимости и примитивность навыков... Очень спорное мнение. Почему при мизерной добавленной стоимости работодатели согласны платить такие высокие зарплаты аналитикам? И есть ли у Вас данные о том, какое количество выпускников общеобразовательных школ обладают всеми необходимыми компетенциями для качественного сбора и документирования требований к ПО?
Именно поэтому я считаю такую организацию труда, при которой сценарии являются вершиной аналитической мысли, убогой (с позиции утилизации аналитических "мощностей"). А аналитиков, расходующих свой ограниченный трудовой ресурс на такого рода работу, вредящими себе. Собственно, они даже аналитикой не занимаются, в контексте определения из первых строк поста.
двусмысленности, неполноты, и несогласованности
Что по Вашему должно являться "вершиной аналитической мысли" вместо ВИ чтобы аналитики не "вредили себе"? Определения могут быть разными и под аналитикой также может пониматься устранение несогласованности, дублирования, противоречий, контроль соответствия бизнес-проблемам и потребностям.
Я не отказываю в праве на существование таким процессам. Иногда они целесообразны и оправданы. Но для хорошего аналитика, или желающего таковым стать, они губительны. ("В совершенстве владеете иностранным языком? Отлично, будете наклеивать марки на конверты!")
И да, я трудился некоторое время аналитиком-сценаристом. Опыт из первых рук.
В каких случаях, по Вашему, такие процессы могут быть целесообразны и оправданы?
-
Мне кажется, что наличие сценариев не противоречит наличию решений.
Не противоречит.
В итоге потребителями выводов и рекомендаций являются владельцы процессов, потребителями сценариев - среда разработки (возможно, не только).
Выводы и рекомендации могут быть даны в спеке, например, в виде макета экранной формы. Кто будет потребителем?
Насколько я понимаю, Вы пытаетесь сказать, что сценарии не могут быть единственным результатом работы бизнес\системного аналитика,
Я высказался о производственных процессах, в которых основным результатом труда аналитика являются сценарии. Если бы таковых не было, высказываться было бы не о чем. Если бы таковые не применялись все шире, высказываться было бы незачем.
а их количество\полнота\качество не являются в итоге критерием качественно выполненной работы аналитика.
Единичные сценарии полнотой не обладают по определению. Это частные случаи. Считать совокупность частных случаев полными требованиями к системе, на мой взгляд, все равно что доказывать сходимость ряда путем торжественной демонстрации конечного числа его элементов.
-
Я высказался о производственных процессах, в которых основным результатом труда аналитика являются сценарии. Если бы таковых не было, высказываться было бы не о чем. Если бы таковые не применялись все шире, высказываться было бы незачем.
Они не применяются всё шире, а наоборот, постепенно сходят со сцены. Но класс систем, в которых они удобны для анализа и описания требований, ещё очень распространён.
-
Леонид, спасибо за Ваше мнение.
Мы все поняли, чем плохи сценарии. Правда, прецедент(он же вариант использования, он же способ применения) является не просто сценарием, а коллекцией (совокупностью) сценариев.
В целом понятна Ваша "нелюбовь" к сценариям. Но не очень понятна правильная альтернатива. Не могли бы Вы очертить, именно, этот подход?
-
Они не применяются всё шире, а наоборот, постепенно сходят со сцены. Но класс систем, в которых они удобны для анализа и описания требований, ещё очень распространён.
Гриша, а на чем зиждется такое утверждение. Очень интересно.
-
... сформирует архитектуру и дизайн системы, закодирует, выполнит сборку, развернёт систему, протестирует, а потом ещё и поддержку осуществлять будет.
Считаете, это является частью работы аналитика?
В жизни, насколько я представляю себе, аналитик будет заниматься только той частью, которой ему поручат заниматься.
Так и есть. Плюс/минут то, что он сам под себя загребет.
"Решения" могут быть разные: аналитические, архитектурные, дизайнерские, реализационные. Не думаю что в крупных проектах рационально возлагать ответственность за все решения на аналитика.
Вероятно. Какое отношение это имеет к тому, что я сказал?
В части проектов аналитику могут поручить только собрать, задокументировать требования и управлять изменениями требований, но не касаться преобразования (принятия решений) требований в модель анализа.
Лично Вы готовы заниматься этим до пенсии? Вы считаете, что эти занятия приведут Вас к вершинам профессии?
В случае если спецификации ВИ написаны качественно, то сценарии будут не разрозненными и неполными, а хорошо структурированными и полными.
Главное, ни в коем случае не добавлять туда новые сценарии.
Почему при мизерной добавленной стоимости работодатели согласны платить такие высокие зарплаты аналитикам?
Не следует ли спросить об этом работодателей? Хотя я бы не стал. Задумаются.
По моему опыту, работодатели сами слабо представляют, что такое аналитик и как его "готовить".
И есть ли у Вас данные о том, какое количество выпускников общеобразовательных школ обладают всеми необходимыми компетенциями для качественного сбора и документирования требований к ПО?
Нет. А Вы с какой целью интересуетесь?
Что по Вашему должно являться "вершиной аналитической мысли" вместо ВИ чтобы аналитики не "вредили себе"?
Написано в первом посте темы.
Определения могут быть разными и под аналитикой также может пониматься устранение несогласованности, дублирования, противоречий, контроль соответствия бизнес-проблемам и потребностям.
Не возражаю. Я даже готов к тому, что аналитикой будет называться процесс проведения общего анализа мочи. Какое отношение это имеет к тому, что я писал в первом посте?
В каких случаях, по Вашему, такие процессы могут быть целесообразны и оправданы?
В ситуациях, когда окружающее определено настолько, что информация для принятия решений (выполнения работ) не требуется или требуется в последнюю очередь.
-
Гриша, а на чем зиждется такое утверждение. Очень интересно.
Присоединяюсь.
-
Мы все поняли, чем плохи сценарии.
Не так. Не сценарии плохи (они верно служат в качестве сырья для формирования требований или же в роли наглядного примера). Плоха подмена ими результатов работы аналитика.
Правда, прецедент(он же вариант использования, он же способ применения) является не просто сценарием, а коллекцией (совокупностью) сценариев.
На практике я больше сталкивался с наборами разрозненных ВИ. И хорошо еще, если исключения в них были хоть как-то отработаны.
Но не очень понятна правильная альтернатива. Не могли бы Вы очертить, именно, этот подход?
Подход заключается в том, чтобы провести весь цикл информационной работы и выдать его результат, а не разложенное на красивые кучки сырье (или полуфабрикат).
-
Гриша, а на чем зиждется такое утверждение. Очень интересно.
Потому что появились довольно широкие классы ПО, в которых взаимодействие пользователя с системой неудобно описывать сценариями. Попробуй описать в виде сценариев работу с Excel, например. Получится очень ограниченный набор требований, который не покроет большей части функциональности. Слишком много путей, все предусмотреть невозможно. То же относится к большинству программ для ПК: текстовые, фото, видеоредакторы - сценариями можно описать какие-то отдельные кусочки взаимодействия, которые всё равно не складываются в мозаику.
Для веб-сайтов сценарный подход тоже оказался неприменим. User Stories возникли не случайно. Это откат назад по сравнению с Use Cases: мы отказывается описывать конкретные сценарии взаимодействия пользователя с системой, оставляя только его цель.
Я буквально вчера отчасти об этом в своём курсе рассказывал, и только что выложил ту часть вебинара, где немного об этом говорю. В частности, почему Вигерс в качестве основного документа требований второго уровня выделяет спецификацию вариантов использования: https://vimeo.com/88255472
Фрагмент получился довольно длинным (40 минут), а собственно рассуждения на эту тему начинаются с отметки 21:58. Хотя я его пересмотрел и обнаружил, что в моих примерах тоже постоянно фигурирует понятие сценария. Но я его понимаю более широко, чем "заданный порядок взаимодействия".
-
Ага, спасибо Гриша. Я понял проблему ВИ, которую ты озвучил, которой правда столько же лет, сколько я знаю, что такое ВИ (не менее 10 лет).
Я соглашусь на 100%, что ВИ не единственный и не исключительный способ описания функциональных требований. Я только не пойму почему это стало вдруг так актуально? Что разве 10 лет назад мы пытались описать работу с Excel через ВИ?
Что значит описание веб-сайтов? Это что, какой-то специфический тип приложения?
Может проблема в том, что мы просто наблюдаем (среди студентов, начинающих аналитиков) преобладание use case driven development? Ну, и это скажем немного раздражает?
-
Подход заключается в том, чтобы провести весь цикл информационной работы и выдать его результат, а не разложенное на красивые кучки сырье (или полуфабрикат).
Леонид, спасибо. Можно, хотя бы кратко, весь цикл инфоработы и его результат?
-
Считаете, это является частью работы аналитика?
Я имел ввиду другое. Степень вклада аналитика (глубина проработки) в разных проектах разная. Поэтому я считаю некорректным устанавливать границу, на которой находится "наивысший возможный вклад аналитика".
Вероятно. Какое отношение это имеет к тому, что я сказал?
Не совсем понятно о каких решениях вы говорите. Насколько глубоко, по вашему, аналитик должен про прорабатывать решение.
Лично Вы готовы заниматься этим до пенсии? Вы считаете, что эти занятия приведут Вас к вершинам профессии?
Предлагаю не обсуждать мои планы. Это не покажет общей картины. По моему опыту степень специализации аналитика, как и других членов команды, зависит от размера и сложности проекта. В крупных проектах высокая специализация более уместна. Вершин можно достичь развиваясь как вширь, так и вглубь.
Главное, ни в коем случае не добавлять туда новые сценарии.
Чем это грозит?
Не следует ли спросить об этом работодателей? Хотя я бы не стал. Задумаются.
По моему опыту, работодатели сами слабо представляют, что такое аналитик и как его "готовить".
Работодатели бывают разные. Даже те, которые "слабо представляют" судя по всему осознают что с аналитиками лучше чем без них.
Нет. А Вы с какой целью интересуетесь?
Вы говорите про мизерность добавленной стоимости и примитивности навыков. Хотелось бы понять на основе чего Вы делаете такие выводы? В большое количество активностей RUP роль аналитика тоже попала по недоразумению?
Не возражаю. Я даже готов к тому, что аналитикой будет называться процесс проведения общего анализа мочи. Какое отношение это имеет к тому, что я писал в первом посте?
Я бы не стал ограничиваться Вашим определением аналитики и на основании этого делать вывод что аналитики не занимаются аналитической работой.
В ситуациях, когда окружающее определено настолько, что информация для принятия решений (выполнения работ) не требуется или требуется в последнюю очередь.
В моем представлении как раз наоборот. ВИ нужны для того чтобы согласовать общее понимание неопределенного окружения.
-
Не так. Не сценарии плохи (они верно служат в качестве сырья для формирования требований или же в роли наглядного примера). Плоха подмена ими результатов работы аналитика.
Сценарии ВИ это не сырье для формирования требований к разрабатываемой программной системе, а наоборот продукт процесса разработки требований, один из способов представления функциональных требований.
-
Потому что появились довольно широкие классы ПО, в которых взаимодействие пользователя с системой неудобно описывать сценариями. Попробуй описать в виде сценариев работу с Excel, например. Получится очень ограниченный набор требований, который не покроет большей части функциональности. Слишком много путей, все предусмотреть невозможно. То же относится к большинству программ для ПК: текстовые, фото, видеоредакторы - сценариями можно описать какие-то отдельные кусочки взаимодействия, которые всё равно не складываются в мозаику.
Для веб-сайтов сценарный подход тоже оказался неприменим.
По большей части, согласен с Григорием. Я на тренинге тоже рассказываю об ограничениях ВИ (в нотации Коберна).
ВИ очень удобны для учетных систем (склад, фильмотека, форум, социальная сеть). Т.е. для сайтов с функционалом они более чем применимы.
Случаи, когда они не очень удобны:
* Проекты по настройке систем. Для разработки багтрекера ВИ прекрасно подходят, а для проекта по настройке багтрекера лучше использовать более высокоуровневые нотации [EPC|State|Data Flow|...] + [табличное описание объектов |XML|...] + ...
* Протоколы интеграции. Примитивный форум сейчас интегрируется с кучей систем. Т эту интеграцию лучше описывать другими нотациями.
* Игромеханика. С помощью ВИ сложно описать шахматы...
Сейчас все чаще настраивают готовые системы, чем пишут с нуля. Ситуация за последние 20 лет изменилась достаточно существенно.
Сейчас все больше интеграций. 20 лет назад системы были более изолированы.
Так что, да: ВИ все еще занимают важную нищу, но ее размер сокращается.
-
Сейчас все чаще настраивают готовые системы, чем пишут с нуля. Ситуация за последние 20 лет изменилась достаточно существенно.
Сейчас все больше интеграций. 20 лет назад системы были более изолированы.
Да, Сергей, спасибо. Интересное наблюдение.
-
Леонид, спасибо. Можно, хотя бы кратко, весь цикл инфоработы и его результат?
Кратко я привел его в первом посте темы:
"Если чуть расширить - различными способами добывает данные, затем их обрабатывает (анализ + синтез + внутричерепная магия), а полученную в результате информацию оформляет и передает потребителю. В идеальном случае, информация принимает форму выводов и рекомендаций для принятия соответствующих решений."
Можно чуть более формализовано:
1. Сбор данных.
2. Систематизация данных.
3. Обработка данных.
4. Получение информации.
5. Выработка решений, выводов, рекомендаций.
Правомерность разделения пунктов 3 и 4 под вопросом. По сути - это две стороны одной медали.
-
Я имел ввиду другое. Степень вклада аналитика (глубина проработки) в разных проектах разная. Поэтому я считаю некорректным устанавливать границу, на которой находится "наивысший возможный вклад аналитика".
Вот колокольня. Ее наивысший возможный вклад (практически, смысл существования) - обеспечить нужную высоту источнику звукового сигнала для его максимального распространения. А вот конкретный проект по разгону облаков, который предполагает другую глубину и степень ее использования. Разгон облаков - штука нужная и полезная. Но колокольню строили для другого.
Не совсем понятно о каких решениях вы говорите. Насколько глубоко, по вашему, аналитик должен про прорабатывать решение.
Решения, подвластные аналитику, могут лежать в области применяемых алгоритмов, наличия отдельных функций, функциональной архитектуры, интерфейсов, политики учета объектов, очередности реализации функционала и т.д, и т.п. Глубина должна быть такой, чтобы его решениями могли пользоваться те, для кого они предназначены.
По моему опыту степень специализации аналитика, как и других членов команды, зависит от размера и сложности проекта. В крупных проектах высокая специализация более уместна. Вершин можно достичь развиваясь как вширь, так и вглубь.
Конечно зависит. И да - можно всю жизнь совершенствоваться, например, в написании сценариев. И помереть непревзойденным мастером сценариев. Разве я против? Только аналитиком его называть неправильно.
Чем это грозит?
Тем, что очередной частный случай развалит всю полноту и непротиворечивость.
Вы говорите про мизерность добавленной стоимости и примитивности навыков. Хотелось бы понять на основе чего Вы делаете такие выводы?
На основании места выдаваемого "продукта" в цепочке создания ценности. Чем ближе к началу - тем ниже добавленная стоимость и тем меньше навыков требуется для ее создания. Аналог - ситуация, в которой некая страна продает сырые углеводороды, а не продукты их переработки.
В большое количество активностей RUP роль аналитика тоже попала по недоразумению?
Я не являюсь знатоком RUP и истории его развития. Ответить не могу.
Я бы не стал ограничиваться Вашим определением аналитики и на основании этого делать вывод что аналитики не занимаются аналитической работой.
Я и не призываю.
В моем представлении как раз наоборот. ВИ нужны для того чтобы согласовать общее понимание неопределенного окружения.
Полагаю, что каждый может позволить себе иметь собственное представление. :)
-
Сценарии ВИ это ... один из способов представления функциональных требований.
Известный подход, в Библии широко применяется. В смысле, когда эксперта спрашивают "как надо?", а тот отвечает притчей. Со всеми вытекающими.
Сценарии могут содержать в себе требования (а также латентные требования, ограничения, рекомендации, исключения, предостережения, приколы и т.п.).
Сценарии не являются требованиями.
-
Вот колокольня. Ее наивысший возможный вклад (практически, смысл существования) - обеспечить нужную высоту источнику звукового сигнала для его максимального распространения. А вот конкретный проект по разгону облаков, который предполагает другую глубину и степень ее использования. Разгон облаков - штука нужная и полезная. Но колокольню строили для другого.
Предназначение колокольни сложно оспорить. К сожалению в нашей профессиональной области нет такого единства в понимании предназначения аналитика.
Решения, подвластные аналитику, могут лежать в области применяемых алгоритмов, наличия отдельных функций, функциональной архитектуры, интерфейсов, политики учета объектов, очередности реализации функционала и т.д, и т.п. Глубина должна быть такой, чтобы его решениями могли пользоваться те, для кого они предназначены.
Конечно зависит. И да - можно всю жизнь совершенствоваться, например, в написании сценариев. И помереть непревзойденным мастером сценариев. Разве я против? Только аналитиком его называть неправильно.
Потребители и производители "аналитического" продукта в разных проектах могут обладать разными компетенциями. Архитектуру могут "навесить" на аналитика, а в другом случае архитектурой будет заниматься главный разработчик или архитектор. Интерфейсы может разрабатывать как аналитик, так и дизайнер. Зависит от процесса разработки, используемого в проекте, и от компетенций членов команды. Почему специалиста с не самой широкой специализацией нельзя назвать аналитиком? И чем вы руководствуетесь при выделении списка решений, подвластных аналитику? Только собственным опытом или какими-то авторитетными источниками?
Тем, что очередной частный случай развалит всю полноту и непротиворечивость.
Это естественно, что требования меняются. Если появится новый сценарий, то он будет добавлен в модель ВИ и полнота будет достигнута. Если новый сценарий будет противоречить уже существующим, то это противоречие будет разрешено по результатам обсуждения с заинтересованными лицами. Можете привести пример, когда эти правила не сработают?
На основании места выдаваемого "продукта" в цепочке создания ценности. Чем ближе к началу - тем ниже добавленная стоимость и тем меньше навыков требуется для ее создания. Аналог - ситуация, в которой некая страна продает сырые углеводороды, а не продукты их переработки.
По моему некорректное сравнение. Если следовать Вашей логике, то на примере производства автомобилей тот кто прикручивает колёса на конвейере будет более квалифицированным, чем тот, кто проектировал двигатель. А в проекции на производство ПО получается что технический писатель, который готовит инструкцию пользователя, будет гораздо более квалифицированным чем разработчик (кодировщик) или архитектор.
Полагаю, что каждый может позволить себе иметь собственное представление. :)
Если я имею представление далёкое от широко распространённого в профессиональной среде, тогда прошу дать мне ссылку на авторитетный источник, который указывал бы, что в ситуациях высокой определённости окружения (требований) использование ВИ более целесообразно чем в други условиях. Буду рад если избавлюсь от своего заблуждения.
-
Известный подход, в Библии широко применяется. В смысле, когда эксперта спрашивают "как надо?", а тот отвечает притчей. Со всеми вытекающими.
Сценарии могут содержать в себе требования (а также латентные требования, ограничения, рекомендации, исключения, предостережения, приколы и т.п.).
Сценарии не являются требованиями.
Авторитетные источники, на основе своего опыта утверждают, что в большинстве случаев вредно совмещать требования и детали проектирования/реализации. "Приколы" конечно тоже могут содержаться в ВИ, даже в форме анекдотов. И это даже будет полезно, если основная цель - улучшить настроение читателя.
-
К сожалению в нашей профессиональной области нет такого единства в понимании предназначения аналитика.
Не готов ручаться за область. Лично у меня это понимание есть.
Потребители и производители "аналитического" продукта в разных проектах могут обладать разными компетенциями. Архитектуру могут "навесить" на аналитика, а в другом случае архитектурой будет заниматься главный разработчик или архитектор. Интерфейсы может разрабатывать как аналитик, так и дизайнер. Зависит от процесса разработки, используемого в проекте, и от компетенций членов команды. Почему специалиста с не самой широкой специализацией нельзя назвать аналитиком?
Разве я говорил, что нельзя? Аналитикой (то есть, информационной работой) могут заниматься все поголовно. В том числе, на благо конкретного проекта. Это никоим образом не меняет назначения колокольни.
И чем вы руководствуетесь при выделении списка решений, подвластных аналитику? Только собственным опытом или какими-то авторитетными источниками?
Собственным опытом и опытом коллег.
Это естественно, что требования меняются. Если появится новый сценарий, то он будет добавлен в модель ВИ и полнота будет достигнута. Если новый сценарий будет противоречить уже существующим, то это противоречие будет разрешено по результатам обсуждения с заинтересованными лицами. Можете привести пример, когда эти правила не сработают?
Сработают в любом случае. Остается лишь небольшой вопрос цены разрешения противоречия. Что нам стоит провести рефакторинг-другой?
По моему некорректное сравнение. Если следовать Вашей логике, то на примере производства автомобилей тот кто прикручивает колёса на конвейере будет более квалифицированным, чем тот, кто проектировал двигатель. А в проекции на производство ПО получается что технический писатель, который готовит инструкцию пользователя, будет гораздо более квалифицированным чем разработчик (кодировщик) или архитектор.
Вы последовали чему-то другому. Я говорил про определенную деятельность определенного специалиста. Вы - про совокупность разных работ, в которых разные специалисты участвуют на разных участках.
Если я имею представление далёкое от широко распространённого в профессиональной среде, тогда прошу дать мне ссылку на авторитетный источник, который указывал бы, что в ситуациях высокой определённости окружения (требований) использование ВИ более целесообразно чем в други условиях. Буду рад если избавлюсь от своего заблуждения.
За ссылками на авторитетные источники - это не ко мне, пожалуйста. Я не испытываю в них потребности. В качестве обобщенного личного опыта отдельных людей, у которых в определенной ситуации неплохо работает то-то и то-то - довольно интересно. Местами изящный "расклад по полочкам" или эффектный ход вызывают желание снять шляпу. Но "авторитеты"? Извините. У меня свой опыт работы имеется. В наших реалиях, с нашим менталитетом и нашими наработками. :)
-
Разве я говорил, что нельзя? Аналитикой (то есть, информационной работой) могут заниматься все поголовно. В том числе, на благо конкретного проекта. Это никоим образом не меняет назначения колокольни.
Собственным опытом и опытом коллег.
Назначения колокольни не меняет, а вот Ваше мнение про назначение аналитика пока остаётся только Вашим субъективным мнением. Я уважаю это мнение, но к сожалению оно пока не подкреплено мнением значительного количества коллег.
Сработают в любом случае. Остается лишь небольшой вопрос цены разрешения противоречия. Что нам стоит провести рефакторинг-другой?
Я говорил не про рефакторинг, а про поддержание актуальности требований, сформулированных в виде ВИ. И ещё... Насколько мне известно рефакторинг проводится не с целью добавления новой функциональности, а с целью улучшения структуры кода.
Вы последовали чему-то другому. Я говорил про определенную деятельность определенного специалиста. Вы - про совокупность разных работ, в которых разные специалисты участвуют на разных участках.
"Определённая деятельность определённого специалиста" складывается из "совокупности разных работ". Вы говорили про место выдаваемого "продукта" в цепочке создания ценности, сравнивали с местом других продуктов в цепочке создания ценности и добавленную стоимость разных продуктов. То есть мы говорили об одном и том же. О совокупности разных работ разных специалистов на разных участках.
За ссылками на авторитетные источники - это не ко мне, пожалуйста. Я не испытываю в них потребности. В качестве обобщенного личного опыта отдельных людей, у которых в определенной ситуации неплохо работает то-то и то-то - довольно интересно. Местами изящный "расклад по полочкам" или эффектный ход вызывают желание снять шляпу. Но "авторитеты"? Извините. У меня свой опыт работы имеется. В наших реалиях, с нашим менталитетом и нашими наработками. :)
Я очень рад если Вам удаётся абсолютно не знакомясь с имеющимся опытом "старших" коллег достигать высоких профессиональных результатов, при этом не наступая на старые грабли. Я же часто сталкивался с ситуацией, когда изучение чужого опыта с "фильтрацией" позволяет облегчить работу.
-
а вот Ваше мнение про назначение аналитика пока остаётся только Вашим субъективным мнением.
Да, я обозначил это в первых строках первого поста. Правда, насчет "только" я не был столь категоричен.
Я уважаю это мнение, но к сожалению оно пока не подкреплено мнением значительного количества коллег.
Если в стане коллег разброд и шатание - ну, тем хуже коллегам. Печально, когда ты сам не определился, кто ты и зачем ты. Но мне кажется, что Вы несколько сгущаете краски. Не все так плохо у коллег.
"Определённая деятельность определённого специалиста" складывается из "совокупности разных работ". Вы говорили про место выдаваемого "продукта" в цепочке создания ценности, сравнивали с местом других продуктов в цепочке создания ценности и добавленную стоимость разных продуктов. То есть мы говорили об одном и том же. О совокупности разных работ разных специалистов на разных участках.
Еще раз: Вы последовали не туда. Если мне не удается это быстро и доходчиво объяснить - видимо, я неважно объясняю. Если вопросы все еще остаются, вернитесь пожалуйста к "истокам". Я там достаточно просто обозначил связь между стадией информационной работы и необходимыми для ее выполнения навыками. Другими словами: чем дальше от начала "цепочки" заходит процесс, тем бОльшими навыками и опытом должен располагать исполнитель.
Я очень рад если Вам удаётся абсолютно не знакомясь с имеющимся опытом "старших" коллег...
Обратите пожалуйста внимание на слова "...В качестве обобщенного личного опыта отдельных людей, у которых в определенной ситуации неплохо работает то-то и то-то - довольно интересно. Местами изящный "расклад по полочкам" или эффектный ход вызывают желание снять шляпу...". Это относится к трудам как известных западных "старших" коллег, так и куда менее известных, но от этого не менее грамотных, коллег отечественных.
-
Дискуссия пошла в какой-то этап взаимных упреков.
Правда, из общей дискуссии я все-таки не понял ключевые позиции Вашего подхода, Леонид. Скорее это похоже на то, что бывает у китайских мастеров гун-фу :) Нужно долго и много заниматься и ты постигнешь это гун-фу, мастерство. Что вообщем-то похоже на правду.
Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.
-
Да, я обозначил это в первых строках первого поста. Правда, насчет "только" я не был столь категоричен.
Хотелось бы услышать мнение других участников форума.
Если в стане коллег разброд и шатание - ну, тем хуже коллегам. Печально, когда ты сам не определился, кто ты и зачем ты. Но мне кажется, что Вы несколько сгущаете краски. Не все так плохо у коллег.
Я говорил про то, что пока не слышал убедительного подтверждения Вашему мнению. Отсутствие у меня такого информации о таком подтверждении не значит что везде разброд и шатание.
Еще раз: Вы последовали не туда. Если мне не удается это быстро и доходчиво объяснить - видимо, я неважно объясняю. Если вопросы все еще остаются, вернитесь пожалуйста к "истокам". Я там достаточно просто обозначил связь между стадией информационной работы и необходимыми для ее выполнения навыками. Другими словами: чем дальше от начала "цепочки" заходит процесс, тем бОльшими навыками и опытом должен располагать исполнитель.
Я прекрасно Вас понял. Такая логика не работает во многих случаях. К примеру написание инструкции пользователя обычно заканчивается после разработки, то есть дальше от начала "цепочки". Действительно ли по этой логике технический писатель должен располагать большими навыками и опытом чем кодировщик?
-
Дискуссия пошла в какой-то этап взаимных упреков.
Правда, из общей дискуссии я все-таки не понял ключевые позиции Вашего подхода, Леонид. Скорее это похоже на то, что бывает у китайских мастеров гун-фу :) Нужно долго и много заниматься и ты постигнешь это гун-фу, мастерство. Что вообщем-то похоже на правду.
Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.
Я пытался сохранять максимальное самообладание и уж точно у меня не было цели кого-то упрекать. У меня есть желание более глубоко разобраться в мнении Леонида. На текущий момент у меня уже не осталось вопросов, хотя во многом я остался не согласен с высказанными идеями.
-
Не могу понять, почему понимание и умение использовать технологию сценариев - убого и вредно. Можно говорить об ограниченности метода.
Что Вы понимаете под "технологией сценариев"?
Сами по себе сценарии ни убоги, ни вредны. Лично мне они бывают полезны:
- в качестве сырья для извлечения требований;
- в качестве наглядного примера в сложных ситуациях;
- в качестве "методов испытаний" при сдаче результатов работ.
Кто-то наверняка может извлечь из них для себя что-то еще.
Убог технологический процесс, в котором аналитические работы оканчиваются разработкой сценариев.
Убог подход, при котом считается, что максимум пользы от аналитика и показатель его мастерства - написание сценариев.
Для аналитика такая ситуация вредна тем, что не дает ему возможности реализовать свой потенциал и получить навыки создания чего-то более ценного и полезного (а если подходить шкурно - еще и увеличить свою стоимость на рынке).
Пример про "стоимость".
На собеседованиях я спрашиваю кандидата о его вкладе в проекты, которыми он занимался. Как правило, человек начинает рассказывать про проведенные обследования, написанные ТЗ, нарисованные схемы. Выслушав, я стараюсь вывести его на несколько иной уровень: а придумал-то ты чего? Что "твоего" в решении, которое сейчас где-то работает и, предположительно, приносит пользу? Если кандидат переходит на истории о том, какую замечательную классификацию учета он разработал, какое придумал решение для разруливания противоречия между требованиями нормативки и реалий, как он предложил и убедил заказчика включить в состав решения новую подсистему, потому что работа без нее означала большие проблемы в ближайшем будущем, как он развел потоки данных так, что заказчик ажно дар речи от счастья потерял - вот это аналитик, который стоит хороших денег (и неважно, что "слегка преувеличил").
Ну а если кандидат продолжает рассказывать о том, что в его ТЗ нормоконтролер носа не подточит, его сценарии строго следуют заветам Вигерса и у него три сертификата по UML - это не совсем аналитик. Это ремесленник с явным превосходством формы над содержанием (что не означает его бесполезности, разумеется).
-
Убог технологический процесс, в котором аналитические работы оканчиваются разработкой сценариев.
Убог подход, при котом считается, что максимум пользы от аналитика и показатель его мастерства - написание сценариев.
Для аналитика такая ситуация вредна тем, что не дает ему возможности реализовать свой потенциал и получить навыки создания чего-то более ценного и полезного (а если подходить шкурно - еще и увеличить свою стоимость на рынке).
Не понимаю, а с чего это Вы взяли? Я не знаю таких процессов и подходов, где все завершается разработкой сценариев.
Да есть подходы и процессы (например унифицированный процесс), в которых представление сценариев служит объединяющим моментов и занимает центральное место, но из их изучения и использования нельзя сделать вывод, что все заканчивается написанием сценариев.
Да и подход во всех случаях один - системный, просто практики разные. Использование сценариев - одна из многих практик. По-моему, вы воюете с ветряными мельницами.
-
Не понимаю, а с чего это Вы взяли? Я не знаю таких процессов и подходов, где все завершается разработкой сценариев.
1. Я в таких местах/проектах работал. Безусловно, от аналитика там требовалось еще что-то: оформить разработанные сценарии в виде определенного документа, консультировать по ним программистов, участвовать в тестировании, поддерживать коммуникации с заказчиками. Но все перечисленное - не аналитика. Аналитика оканчивалась разработкой сценариев. Попытки влезть с советами по поводу организации информационных объектов, проектирования интерфейсов, межсистемного взаимодействия бодро пресекались. Мол, это дело архитекторов и программистов.
2. Я периодически вижу всякого рода тестовые задания, в которые входит, или которые состоят из чего-то вроде "докажи, что ты аналитик - напиши сценарий". Это дает мне основания полагать, что работа у авторов таких тестов в чем-то сходна с п.1.
Да есть подходы и процессы (например унифицированный процесс), в которых представление сценариев служит объединяющим моментов и занимает центральное место, но из их изучения и использования нельзя сделать вывод, что все заканчивается написанием сценариев.
"Все теории стоят одна другой", в хорошем смысле. Я же говорю про практику, в которой участвовал и/или которую наблюдаю воочию. И признаки которой продолжаю наблюдать в самых разных ситуациях.
По-моему, вы воюете с ветряными мельницами.
Разве я воюю?
-
1. Я в таких местах/проектах работал. Безусловно, от аналитика там требовалось еще что-то: оформить разработанные сценарии в виде определенного документа, консультировать по ним программистов, участвовать в тестировании, поддерживать коммуникации с заказчиками. Но все перечисленное - не аналитика. Аналитика оканчивалась разработкой сценариев. Попытки влезть с советами по поводу организации информационных объектов, проектирования интерфейсов, межсистемного взаимодействия бодро пресекались. Мол, это дело архитекторов и программистов.
Ну действительно, чего же хлеб у архитекторов и программистов отнимать :)
К тому же, нормальное разделение труда. Правда, только сценариями же систему не опишешь.
-
Ну действительно, чего же хлеб у архитекторов и программистов отнимать :)
К тому же, нормальное разделение труда. Правда, только сценариями же систему не опишешь.
Действительно. Зачем нужно мнение аналитика с его бизнес-интересами? Ведь все, что знает, он уже написал. Пусть идет на следующий проект, там сценарии еще не написаны. Остальное - дело серьезных пацанов и технологических инноваций. :)
Правда, только сценариями же систему не опишешь.
Это мелочи. Остальное программисты сами придумают - они же Программисты, а не быдлокодеры. А в случае чего, ПМ отправит аналитика убеждать Заказчика, что это именно то, что тому надо. Ну, чтобы лишний раз административный ресурс не беспокоить.
-
Леонид, видимо, Вам серьезно досталось. Сочувствую.
-
Леонид, видимо, Вам серьезно досталось. Сочувствую.
Благодарю за участие, но сочувствовать право не стоит. Рассматриваемый феномен обрел силу лишь последние лет 5, и лично мне повредить уже не может.
А вот относительно начинающих жаль. Кто-то искренне считает, что если в названии его должности есть слово "аналитик", то занимается он аналитикой. Или, глядя на особо креативное тестовое задание - что это он дурак (ведь составитель задания априори мудр и знает, что делает). Или терзается конкретным вопросом навроде "куда вставить последний сценарий в ТЗ по ГОСТ" слегка подозревая, что туда и первый вставлять не стоило. Сложно сегодня становиться аналитиком. :)
-
А вот относительно начинающих жаль. Кто-то искренне считает, что если в названии его должности есть слово "аналитик", то занимается он аналитикой. Или, глядя на особо креативное тестовое задание - что это он дурак (ведь составитель задания априори мудр и знает, что делает). Или терзается конкретным вопросом навроде "куда вставить последний сценарий в ТЗ по ГОСТ" слегка подозревая, что туда и первый вставлять не стоило. Сложно сегодня становиться аналитиком. :)
К счастью, мне неизвестна подобная ситуация. Не было прецедентов, в которых подобное происходило. Но все-таки некоторое неумное мнение, хотя и дискредитирует подход, все-таки не делает его убогим и вредным.
-
К счастью, мне неизвестна подобная ситуация. Не было прецедентов, в которых подобное происходило. Но все-таки некоторое неумное мнение, хотя и дискредитирует подход, все-таки не делает его убогим и вредным.
Эдуард, полагаю, в нашем разговоре имеет место различное применение терминологии. Скорее всего (поправьте, если ошибаюсь), Вы под "подходом" подразумеваете часть некой методологии (или ряда различных методологий), которая связана с разработкой и применением сценариев. Часть, которая органично вшита в методологию и служит определенным целям.
Я же, говоря про "подход", имею ввиду исключительно практику работы организации, подразделения внутри организации или даже отдельной проектной группы. Практику, которая сложилась из совокупности благих намерений руководства, "корпоративной культуры", усилий организаторов, рационализаторской активности аборигенов, баланса авторитетов внутри организации (отдела, группы), специфики выполняемых проектов и т.п. Эта практика, как правило, имеет мало общего с любыми распространенными методологиями, как бы ее не называли создатели и как бы ни били себя пятками в грудь на предмет "Мы работаем по [вставить название]!".
Но зато только такие практики и существуют на самом деле. В них мы работаем. Не в стройных ГОСТ, RUP или Agile, а в их живых "внедрениях" на местах. Разница получается примерно как между моделью с обложки и реальной женщиной. Которая местами даст "обложке" 100 очков вперед, а где-то - сука сукой. И по другому не будет. Невозможно работать по MSF [вставить свое название] в чистом виде. Ну, просто потому, что ты не Майкрософт в период становления методологии.
Так вот "убогими" и "вредными для аналитика" я называю определенную часть реальных подходов, не замахиваясь на вершины теоретических изысканий и шедевры (практически без иронии) авторитетов.
-
Так вот "убогими" и "вредными для аналитика" я называю определенную часть реальных подходов, не замахиваясь на вершины теоретических изысканий и шедевры (практически без иронии) авторитетов.
Я согласен, Леонид, когда работу любого человека пытаются загнать в определенные рамки. Правда, особенность современных методологий заключается в том, что они есть суть не теоретически выведенные, а результат практики. Они по сути так и называются - практики. Тот же RUP - это не теория - это практика. Потому мне не понятны Ваши выводы, что мол вот есть какая-то абстрактная теория типа MSF, а у нас вот в реальности все по-своему.
Практика и есть практика, что есть некоторые общие рекомендации, а в реальности много определяется теми людьми, их характерами, их прозорливостью или заблуждениями, которые собственно и внедряют их. Понятно и то, что опытному человеку не нужны чужие практики или чужие обобщения, если он сам ясно и глубоко понимает суть и детали.
Вы же сейчас утверждаете, что использование и обучение в стиле сценарного подхода (которого я сам не знаю, знаю системный подход ) убого и вредно. Получается, что я как преподаватель, который в рамках того или иного курса требую от студента техники описания юз кейсов, убог и вреден.
Или если я в своей работе использую сценарии в аналитической работе и рекомендую это своим коллегам - убог и вреден.
Скорее всего Вы имели в виде вовсе не это, но что тогда? Ваш личный опыт, Ваше личное наблюдение?
Я работаю в компании, где НЕ используют варианты использования и сценарный подход. Но по-моему, в ней вообще ничего из имеющихся практик явно не используется. Правильно ли будет в этом случае, считать все эти практики убогими, только по той причине, что их мы не используем и не понимаем как и зачем их использовать? Может проблема масштаба?
Леонид, реально, я считаю Вас отличным специалистом. Это следуют из того, как Вы комментируете те или иные сообщения, какие даете советы. Думаю, что наши разногласия базируются на непонимании.
-
...особенность современных методологий заключается в том, что они есть суть не теоретически выведенные, а результат практики...
Почему обязательно современных? 19-я серия ГОСТ конца 70х отнюдь не измышления глубоких теоретиков. Насколько я представляю из прочитанных "источников" и личного опыта, с разработкой медологии дело обстоит примерно так: работали-работали солидные люди, потом подумали: "А чего бы не увековечить наши классные методические наработки?" (или начальство за них так подумало). Подумали - сделали. Собрали опыт, обобщили, выделили отдельные методы, сплели их в методологию и вуаля. В основу солидного тома ложится обобщенный опыт реальных проектов, чуть-чуть скорректированный с учетом "а вот если бы мы делали это сегодня, то сделали бы умнее, наверное вот так". И методология даже работает - у ее авторов (за исключение части "сделали бы умнее", но к ней стремятся). Авторы вполне могут показать, как каждая строчка из методологии вплетена в их процессы и пояснить, зачем она там.
(предлагаю для простоты считать, что методология разрабатывается инженерами с намерениями сделать мир лучше, а не маркетологами с целью заработать)
То есть, латентная методология жила себе и помогала жить другим в какой-то вполне определенной среде: культурной, традиционной, языковой, корпоративной, профессиональной, кадровой и т.д и т.п. Как-то во всем этом работала. Затем ее оттуда вынули, дистиллировали, формализовали и выдали на гора. В результате этого процесса она потеряла свои корни и питательную среду. И из пышно зеленеющего где-то древа превратилась в сухую универсальную теорию.
Они по сути так и называются - практики.
По моему глубокому убеждению, практики - они на реальном предприятии. Буквы внутри обложки - это теория и советы. Что бы при этом ни было написано на обложке.
Тот же RUP - это не теория - это практика.
В IBM - вполне возможно, не видел. Хотя в последние годы, судя по зверинцу и содержанию продуктов, у них не RUP правит бал, а маркетинговое "скупим всех". А как там эти "все" работают - кто ж их знает? (да и кому вообще это надо, работают - и ладно).
Потому мне не понятны Ваши выводы, что мол вот есть какая-то абстрактная теория типа MSF, а у нас вот в реальности все по-своему.
...
Я работаю в компании, где НЕ используют варианты использования и сценарный подход. Но по-моему, в ней вообще ничего из имеющихся практик явно не используется.
Вот. И так - практически везде. "Практически" говорю потому, что оставляю ничтожно малую вероятность, что кто-то все-таки умудрился выстроить у себя "настоящий" RUP, Agile или какой другой MSF (не исключено, что на свою беду).
Отсюда мои выводы.
Практика и есть практика, что есть некоторые общие рекомендации, а в реальности много определяется теми людьми, их характерами, их прозорливостью или заблуждениями, которые собственно и внедряют их.
Аминь. То, что они внедрили, и есть практика. А то, с чего внедряли - теория и рекомендации.
Вы же сейчас утверждаете, что использование и обучение в стиле сценарного подхода (которого я сам не знаю, знаю системный подход ) убого и вредно.
Не припомню. Можно ссылку? И, кстати, я тоже не знаю, что такое "сценарный подход". Я говорил про подходы в производственных процессах, при которых сценарии являются итогом работы аналитика.
Получается, что я как преподаватель, который в рамках того или иного курса требую от студента техники описания юз кейсов, убог и вреден.
Не получается.
Или если я в своей работе использую сценарии в аналитической работе и рекомендую это своим коллегам - убог и вреден.
Я немного выше писал, что сам использую сценарии в работе. Как минимум, в трех направлениях. И даже, помнится, советовал в какой-то теме, куда их деть в ГОСТовой документации.
Скорее всего Вы имели в виде вовсе не это, но что тогда? Ваш личный опыт, Ваше личное наблюдение?
Я пишу на основании своего опыта, наблюдений, понимания предмета работы аналитика.
В этой теме пишу про процесс производства ИТ-решений, в котором, помимо аналитики, задействована масса народа других специальностей. И про ту роль, которая в этой суете отводится аналитикам.
Правильно ли будет в этом случае, считать все эти практики убогими, только по той причине, что их мы не используем и не понимаем как и зачем их использовать?
Полагаю, что считать что-то убогим следует лишь тогда, когда разобрался и понимаешь, почему именно следует так считать.
Может проблема масштаба?
Не понял вопроса. Можно пояснить?
Думаю, что наши разногласия базируются на непонимании.
Прекрасно. Для меня было весьма ценно найти "общий знаменатель".