2 Се ля ви, 
все надеюсь на продолжение разговора  

Сорри за оффтоп 
Кстати, ЖЖ у тебя супер! Прочитал весь и попутно твой креатив про программистов - респект! Очень многое совпадает с моими взглядами  Было очень интересно 

Aazmandius, как-то немного сумбурно...

Прежде всего - ты уверен, что ты годишься на роль аналитика? Что это будет хорошо у тебя получаться?


Нехило! 

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

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


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

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

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


Во-первых, никого не будет интересовать, как ты это делаешь - все эти анализы ты можешь проводить сам, если они тебе чем-то помогут, но боюсь, что нет. Ты просто первое время будешь безуспешно прятать за ними свой непрофессионализм и именно так это будет восприниматься со стороны. Во-вторых,
1. Программистам от тебя нужно будет конкретное детальное описание задачи, и желательно что бы это было по-проще реализовывать,
2. пользователям нужно будет, что бы конечная система делала им "хорошо", а конкретизировать им трудно, при чём разные пользователи хотят всё по-разному,
3. Заказчику надо, что бы система стоила по-меньше, была готова к заявленному сроку, что бы она максимизировала прибыли и с ней было по-меньше хлопот.

А если ты ещё и работаешь не внутри конторы заказчика, то есть ещё и четвёртая сторона - твоё собственное руководство, у которого тоже свои интересы.

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


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

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

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

Согласен 100%! Так и стараюсь работать (в пределах своих девелоперских полномочий конечно  )

То есть ты предлагаешь описать эту должность с точки зрения занимаемого положения в организации?  Честно говоря, как оно в больших компаниях - я даже не представляю  Сейчас работаю в относительно небольшой компании (хотя проекты тут серьезные и большие, автоматизируем страховые компании), тут все в общем-то многостаночники  и кроме директоров из начальства есть только лидеры групп, которые всем и занимаются - и анализом, и проектами руководят, и кодят наравне со всеми  Надо сказать, все у них получается хорошо, что б ни говорили по поводу того, что нельзя одновременно вести проекты и их же разрабатывать - на каждой группе по 3 проекта висит, и все окей  Короче, XP+Agile рулят  И отношения между людьми на 90% дружеские, и с начальством в т.ч. А вот как оно в больших конторах, я могу только догадываться 

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

по-моему могут рещаться в рамках экстремального программирования, недаром оно мне так нравится (хотя может я и заблуждаюсь - реально ведь проектом не руководил никогда ) 

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

И отдельное данке за предупреждения

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

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

Прочитала вопрос: "как стать системным аналитиком?" и захотелось простонать в ответ: "а может, не надо?....."

  

Прежде всего необходимо получить техническое образование.
Заостряю внимание - ТОЛЬКО техническое! гуманитарный цикл или естественно-научный тут не пойдет, т.к. вам потребуется математика в объеме 3 курсов, чтобы научиться правильно мыслить.
98% аналитиков это люди с высшим образованием.

Затем необходимо поработать в течение 2-3 лет в сфере автоматизации.

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

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

Прочитать следующие книги:
Разработка требований к ПО
Объектно-ориентированное моделирование и разработка
Методы описания функциональных требований
Анализ требований и проектирование систем
первые две - необходимо, остальные - опционально.

Развить коммуникативные навыки:
1. Проведение интервью
2. Телефонное общение
3. Деловая переписка

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

Важно свято помнить 2 вещи:

1. Никакие инструментальные средства тебе не помогут, если ты не знаешь, КАК создавать модели. А для этого нужно знать, что такое объектно-ориентированный анализ и в какой последовательности его осуществлять. Модель - это результат умственного труда аналитика, а не работы программы. Она создается в голове, и лишь потом переносится в память ЭВМ.

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

Это сообщение отредактировал(а) Се ля ви - 22.4.2007, 15:31

Спасибо за советы, обязательно постараюсь все учесть  Все, что описано, в той или иной мере присутствует =) Образование у меня будет именно техническое (ф-т Компьютерных Наук) и математику и всевозможные моделирования систем разных видов (математическое, динамическое, объектный подход...) нам читали и читают, так что суть создания модели я понимаю и это у меня получается, более того - это мне нравится  Конечно, уровень моих умений пока невысок, но база уже заложена, суть я в той или иной мере ухватил - буду совершенствоваться  ООА уже настолько въелся в мой мозг, что как когда-то разработки велись по другому я себе уже слабо представляю. Так что тут тоже остается только расти выше, суть опять-таки понятна. А вот 
 и чтение перечисленных книг мне только предстоит  Коммуникативные навыки есть, с людьми схожусь и нахожк общий язык достаточно легко, теперь нужно будет только научиться делать это максимально правильно 

Большое спасибо за очерчивание круга TODO's  Буду продвигаться в этом направлении. Если есть еще какие-нибудь дополнительные замечания или пожелания - с радостью выслушаю 

З.Ы.: +1 to ida и Се ля ви
За активное участие, советы и помощь 

Чтобы не создавать тему, пишу здесь. Купил книгу Рамбо и Блаха "UML 2.0. Объектно-ориентированное моделирование и разработка" 2-е издание.
Вначале, где описываются этапы процесса разработки.
1. Концептуализация системы.
2.Анализ.
3. Проектирование системы.
4. Проектирование классов.
5. Реализация.

На 1м этом этапе создается ТЗ со всеми требованиями? Или же требования дорабатываются и на следующем этапе? То есть концептуализация системы и анализ связаны друг с другом циклом и только после определенного количества итераций ТЗ готово и только затем передается на этап проектирования системы?
Относительно этапа 2. Создвается модель предметной области и модель приложения. Модель приложения - способ отображения программы, цветовая гамма, кнопочки и менюшки (с соответствующими обработчиками), и все прочее? А модель предметной области - это основное, вся программная начинка. Я правильно понял? 

Gunslinger, в общем случае - и так и так можно. А конкретнее, не знаю, как Блах, но Рамбо вроде бы приверженец RUP`а, а это -  модель, которая предполагает доработку требований на всём этапе разработки продукта с уменьшающейся активностью. Вот так это выглядит на графике -



Если интересно более подробно, почитай что-нибудь про RUP.

Это сообщение отредактировал(а) Се ля ви - 22.4.2007, 15:30

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

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

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

Это сообщение отредактировал(а) ida - 23.4.2007, 09:16

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

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

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

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

Gunslinger, могу ответить цитатой из Мартина Фаулера:



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

Это сообщение отредактировал(а) Се ля ви - 24.4.2007, 11:30

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

Главное, понимать, какие классы вы моделируете - предметной области или программные 
Первое часто полезно. Второе ИМХО в промышленной разработке ни к чему.

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

ИМХО - неверно. 
Аналитик - не посредник. Задача аналитика - разобраться в процессах и их взаимосвязи, создать модель эффективной работы организации. Т.е. "заполнить черный ящик". На входе у этого ящика - внешние воздействия на организацию (отдел, участок ...), на выходе - реакция на эти воздействия. Внутри - ресурсы, их распределение, взаимодействие. Это не посредничество. Это достаточно муторная и неблагодарная работа - разобраться в функционале объекта автоматизации (далее ОА) и создать модель его эффективной работы. Просто посредничеством тут не обойдешься, поскольку заказчик хочет, чтобы "было хорошо", но при этом как правило существующая схема работы - из рук вон плохая, требуется переделка связей и функций  внутри ОА. И соответственно имеем главную проблему: проблему доверия заказчика. Его нужно убедить в том, что нужно изменение. Для этих целей и служат всякие диаграммы, авторитет разработчика и т.п. Отсюда - 2 задачи аналитика:
1. Построить правильную модель ОА.
2. Убедить заказчика, что она правильна (или замаскировать под что-то ему понятное и приемлемое).
И дальше аналитик корректирует модель по следам жизненных пертурбаций.
Архитектор получает модель и определяет - какими средствами ее воплотить в жизнь. Ну и раздает задачи програмистам.
Программист, получив задачу, разбивает ее на фукциональные блоки и раскидывает по кодерам, которые находятся в самой нижней части иерархии.  
Соответственно кодер, имея фунцию, которую нужно реализовать, ее кодит .
Результаты кодинга скидываются тестерам, те в меру вредности капают на мозги программистам, которые либо просто спихивают ошибки на исправление кодерам, либо еще и функциональные блоки переделывает и опять же на кодеров спихивает.
Ну и т.д.
Относительно сбоку от основного производственного процесса - дизайнер, тех.писатель, техсаппорт.
Дизайнер пудрит мозги программистам и кодерам, где, что и как должно располагаться и быть выкрашено.
Тех.писатель на доступном 5-класснику языке расхваливает в документации (будущий) продукт и на какую кнопку там нужно нажать, чтобы Doom был спрятан за отчетом о поставке фигурных скрепок смежной конторе .
Что делает техсаппорт - все знают.

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

Ну и соответственно практический вывод: поскольку, как нетрудно заметить, крупных проектов мало, чисто системных аналитиков практически нет. И планировать себе профессию системного аналитика примерно так же перспективно, как профессию директора коммерческого банка. Во всяком случае я у себя в городе таких живьем не видел. 
Другой вопрос, что в силу поголовного совместительства программисту (если он действительно программист, а не кодер) просто необходимы навыки и аналитика, и архитектора, и дизайнера. Иначе он такое урючище напрограммирует, что смотреть будет тошно, не то что работать. Что впрочем я и наблюдаю периодически. Поскольку
Это не программист. Кодер. Считающий себя программистом.

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

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

Аналитик это посредник, т.к. заказчик не общается напрямую с программистами. Вы понимаете смысл слова "посредник"?  ПОСРЕДством ТЗ программист получает требования заказчика. А ТЗ пишет аналитик.

Больших проектов много. Поэтому чистые системные аналитики есть.
Утверждаю из опыта.