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

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

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

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

1. Я в таких местах/проектах работал. Безусловно, от аналитика там требовалось еще что-то: оформить разработанные сценарии в виде определенного документа, консультировать по ним программистов, участвовать в тестировании, поддерживать коммуникации с заказчиками. Но все перечисленное - не аналитика. Аналитика оканчивалась разработкой сценариев. Попытки влезть с советами по поводу организации информационных объектов, проектирования интерфейсов, межсистемного взаимодействия бодро пресекались. Мол, это дело архитекторов и программистов.

2. Я периодически вижу всякого рода тестовые задания, в которые входит, или которые состоят из чего-то вроде "докажи, что ты аналитик - напиши сценарий". Это дает мне основания полагать, что работа у авторов таких тестов в чем-то сходна с п.1.

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

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

По-моему, вы воюете с ветряными мельницами.

Разве я воюю?

1. Я в таких местах/проектах работал. Безусловно, от аналитика там требовалось еще что-то: оформить разработанные сценарии в виде определенного документа, консультировать по ним программистов, участвовать в тестировании, поддерживать коммуникации с заказчиками. Но все перечисленное - не аналитика. Аналитика оканчивалась разработкой сценариев. Попытки влезть с советами по поводу организации информационных объектов, проектирования интерфейсов, межсистемного взаимодействия бодро пресекались. Мол, это дело архитекторов и программистов.

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

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

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

Правда, только сценариями же систему не опишешь.

Это мелочи. Остальное программисты сами придумают - они же Программисты, а не быдлокодеры. А в случае чего, ПМ отправит аналитика убеждать Заказчика, что это именно то, что тому надо. Ну, чтобы лишний раз административный ресурс не беспокоить.

Леонид, видимо, Вам серьезно досталось. Сочувствую.

Леонид, видимо, Вам серьезно досталось. Сочувствую.

Благодарю за участие, но сочувствовать право не стоит. Рассматриваемый феномен обрел силу лишь последние лет 5, и лично мне повредить уже не может.

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

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

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

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

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

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

Но зато только такие практики и существуют на самом деле. В них мы работаем. Не в стройных ГОСТ, RUP или Agile, а в их живых "внедрениях" на местах. Разница получается примерно как между моделью с обложки и реальной женщиной. Которая местами даст "обложке" 100 очков вперед, а где-то - сука сукой. И по другому не будет. Невозможно работать по MSF [вставить свое название] в чистом виде. Ну, просто потому, что ты не Майкрософт в период становления методологии.

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

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

Я согласен, Леонид, когда работу любого человека пытаются загнать в определенные рамки. Правда, особенность современных методологий заключается в том, что они есть суть не теоретически выведенные, а результат практики. Они по сути так и называются  - практики. Тот же RUP - это не теория - это практика.  Потому мне не понятны Ваши выводы, что мол вот есть какая-то абстрактная теория типа MSF, а у нас вот в реальности все по-своему.

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

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

Скорее всего Вы имели в виде вовсе не это, но что тогда? Ваш личный опыт, Ваше личное наблюдение?

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

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

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

Почему обязательно современных? 19-я серия ГОСТ конца 70х отнюдь не измышления глубоких теоретиков. Насколько я представляю из прочитанных "источников" и личного опыта, с разработкой медологии дело обстоит примерно так: работали-работали солидные люди, потом подумали: "А чего бы не увековечить наши классные методические наработки?" (или начальство за них так подумало). Подумали - сделали. Собрали опыт, обобщили, выделили отдельные методы, сплели их в методологию и вуаля. В основу солидного тома ложится обобщенный опыт реальных проектов, чуть-чуть скорректированный с учетом "а вот если бы мы делали это сегодня, то сделали бы умнее, наверное вот так". И методология даже работает - у ее авторов (за исключение части "сделали бы умнее", но к ней стремятся). Авторы вполне могут показать, как каждая строчка из методологии вплетена в их процессы и пояснить, зачем она там.

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

То есть, латентная методология жила себе и помогала жить другим в какой-то вполне определенной среде: культурной, традиционной, языковой, корпоративной, профессиональной, кадровой и т.д и т.п. Как-то во всем этом работала. Затем ее оттуда вынули, дистиллировали, формализовали и выдали на гора. В результате этого процесса она потеряла свои корни и питательную среду. И из пышно зеленеющего где-то древа превратилась в сухую универсальную теорию.

Они по сути так и называются  - практики.

По моему глубокому убеждению, практики - они на реальном предприятии. Буквы внутри обложки - это теория и советы. Что бы при этом ни было написано на обложке.

Тот же RUP - это не теория - это практика. 

В IBM - вполне возможно, не видел. Хотя в последние годы, судя по зверинцу и содержанию продуктов, у них не RUP правит бал, а маркетинговое "скупим всех". А как там эти "все" работают - кто ж их знает? (да и кому вообще это надо, работают - и ладно).

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

Вот. И так - практически везде. "Практически" говорю потому, что оставляю ничтожно малую вероятность, что кто-то все-таки умудрился выстроить у себя "настоящий" RUP, Agile или какой другой MSF (не исключено, что на свою беду).
Отсюда мои выводы.

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

Аминь. То, что они внедрили, и есть практика. А то, с чего внедряли - теория и рекомендации.

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

Не припомню. Можно ссылку? И, кстати, я тоже не знаю, что такое "сценарный подход". Я говорил про подходы в производственных процессах, при которых сценарии являются итогом работы аналитика.

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

Не получается.

Или если я в своей работе использую сценарии в аналитической работе и рекомендую это своим коллегам - убог и вреден.

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

Скорее всего Вы имели в виде вовсе не это, но что тогда? Ваш личный опыт, Ваше личное наблюдение?

Я пишу на основании своего опыта, наблюдений, понимания предмета работы аналитика.
В этой теме пишу про процесс производства ИТ-решений, в котором, помимо аналитики, задействована масса народа других специальностей. И про ту роль, которая в этой суете отводится аналитикам.

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

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

Может проблема масштаба?

Не понял вопроса. Можно пояснить?

Думаю, что наши разногласия базируются на непонимании.

Прекрасно. Для меня было весьма ценно найти "общий знаменатель".