Форум Сообщества Аналитиков
Обсуждения => Работа => Тема начата: Tigra от 27 Февраля 2009, 17:36:54
-
Приветствую всех участников форума.
Вот возникло несколько вопросов и очень надеюсь получить на них здесь ответы.
Итак, полтора года назад мне вручили красные корочки, в которых написано «квалификация Инженер по специальности «информационные системы и технологии». Поскольку гонять код целыми днями меня совершенно не привлекало, решила податься в тестеры, кем и работаю до сих пор. Скукотища жуткая. Поначалу было интересно, а сейчас просто тоска сплошная.
Еще в процессе обучения мне нравилось проектировать БД, продумывать ER-диаграммы, изображать бизнес-процессы…Ну как вы, конечно, понимаете, все это на сугубо учебном дилетантском уровне. Не могу сказать, что я прихожу от всего этого в восторг, но, по крайней мере, из всех айтишных направлений это единственное, что меня привлекает. Но! На работу меня, разумеется, никто не берет и не зовет, потому что опыта работы аналитиком жирный ноль, настоящий опыт работы тестером представляется весьма сомнительным для работодателя, да и теоретических знаний немного.
Итак, имеем. Цель: попасть в ряды аналитиков (бизнес- или системных, я не определилась. Может быть, вы мне поможете? Позадаете наводящие вопросы, сделаете соответствующие выводы). Поставленные задачи: весьма пока туманны. Раз отсутствует опыт, то нужно подковаться хотя бы теоретически, попрактиковаться на тренировочных моделях, почитать книги. Прочитала UML основы Фаулера, в процессе «UML. Руководство пользователя” и «Разработка ИС с использованием UML».
Двигаюсь ли я в нужном направлении и что нужно делать дальше?
Очень надеюсь на вашу помощь. Безумно хотелось бы разобраться в себе и конкретно определиться, что мне нужно ( я имею ввиду в профессиональном, а не психологическом плане :)). А это, к сожалению, без вовремя данного совета грамотного человека, маловозможно.
С уважением к форуму,
Tigra :)
-
А вы знаете процент людей, которые в восторге от своей работы? :)
У меня тяга к творчеству, рисованию, дизайну...Но к аналитике это не имеет никакого отношения. Давайте лучше по делу ;)
-
У меня тяга к творчеству, рисованию, дизайну...Но к аналитике это не имеет никакого отношения. Давайте лучше по делу ;)
Почему не имеет отношения? Очень даже имеет. Задача аналитика - не только анализировать, но и создавать образ разрабатываемой системы. И даже, пожалуй, не столько анализировать, сколько создавать.
Но вот так, на первый взгляд, почему бы не попробовать заняться веб-дизайном? Или стать экспертом usability? Грамотный дизайнер, разбирающийся в технологии - светлая мечта каждого программиста (зачастую несбыточная). :)
Ну и вообще:
Выносил я как-то мусорный бак. Замерз. Опрокинул его метра за три до помойки. Минут через пятнадцать к нам явился дворник. Устроил скандал. Выяснилось, что он по мусору легко устанавливает жильца и номер квартиры.
В любой работе есть место творчеству.
С. Довлатов, Соло на ундервуде (http://www.lib.ru/DOWLATOW/dowlatow.txt)
-
Веб-дизайнеров, извините, как собачек нерезанных :-) И я, хоть и обладаю некоторыми творческими способностями и чрезвычайной усидчивостью, трезво оцениваю свою ненужность данной отрасли...
А эксперт юзабилити это кто? Это дизайнер интерфейсов? Я думала об этом. Их требуется очень мало и очень редко...При этом опять же опыта ноль, нужны какие-то грамотные сертификаты, на которые у меня денег нет :(
-
Веб-дизайнеров, извините, как собачек нерезанных :-) И я, хоть и обладаю некоторыми творческими способностями и чрезвычайной усидчивостью, трезво оцениваю свою ненужность данной отрасли...
А эксперт юзабилити это кто? Это дизайнер интерфейсов? Я думала об этом. Их требуется очень мало и очень редко...При этом опять же опыта ноль, нужны какие-то грамотные сертификаты, на которые у меня денег нет :(
Их требуется всё больше. И на хороших специалистов всегда есть спрос, причём не вопреки, а благодаря конкуренции, а "красные корочки" косвенно свидетельствуют о возможности стать хорошим специалистом.
Но если интересен анализ, то начинать надо imho не с UML. UML - это всего лишь язык, одно из средств выражения некоторых мыслей. Были бы мысли, а языки найдутся.
В файловом архиве сайта (http://www.uml2.ru/index.php?option=com_remository&Itemid=28) есть кое-что для чтения. Я бы посоветовал начать c Леффингуэлла и Вигерса, если ещё не читали. Это об управлении требованиями.
-
Но я ведь написала о том, что аналитика мне интересна. Она не является моей голубой мечтой, но она мне интересна...Я думаю это уже немало. А мои жалкие потуги к творчеству вполне устраивают меня в качестве хобби :-)
Возможно, к 30 годам я и захочу все поменять, что же в этом плохого? Или нужно обязательно всю жизнь посвящать одному делу? :)
Вопрос сейчас стоит не в стиле “ой, ребята, я тут 11 класс закончила, куда пойти учиться-то, аааа?». Я хотела бы понять, к какой части этой великой науки мне склониться, и как саморазвиться хотя бы до того уровня, чтоб потенциальный работодатель проявил хоть какой-то интерес, а в счастливом случае принятия меня, предоставил мне простор для практики и развития себя, как профессионала?
-
Больше читайте.
Изучайте философию, искусство, физику, химию и т.п. Все пригодится
Изучайте системный анализ, практики анализа, методы анализа
Решайте задачи разные и много
Изучайте технологии и методологии разработки
Учитесь понимать требования, выдвигайте свои требования, пытайтесь придумать, как решить эти требования.
-
моделях, почитать книги. Прочитала UML основы Фаулера, в процессе «UML. Руководство пользователя” и «Разработка ИС с использованием UML».
Двигаюсь ли я в нужном направлении и что нужно делать дальше?
Зря. Эти книги стоит читать потом. И то всего лишь "может быть".
У Дениса Бескова найдите в блоге список рекомендованных книг. Вот их и читайте.
От себя еще порекомендую "Психбольница в руках пациентов".
-
Я пыталась читать какие-то книги по проектированию, но то ли я слишком неопытна, то ли еще в чем дело, все они мне кажутся какими-то уж больно далекими от реальности. По крайней мере я вижу аналитиков в нашей компании (крупная фирма), вижу, чем они занимаются, и уровень этих «умных» книг и реальной работы наших аналитиков даже рядом не стоит.
-
Больше читайте.
Изучайте философию, искусство, физику, химию и т.п. Все пригодится
Изучайте системный анализ, практики анализа, методы анализа
Решайте задачи разные и много
Изучайте технологии и методологии разработки
Учитесь понимать требования, выдвигайте свои требования, пытайтесь придумать, как решить эти требования.
Звучит все чрезмерно абстрактно. Как в университете на лекции было... Связи между этими лекциями и реальной жизнью я, правда, пока не увидела. Пригодилось мне только то, что делали на практических занятиях - те же самые модели баз данных, к примеру.
-
Зря. Эти книги стоит читать потом. И то всего лишь "может быть".
А в ответе на вакансию, где написано в реквайроментах UML, я что отвечу? Прочитала книжки такие-то и такие-то? :)
-
Зря. Эти книги стоит читать потом. И то всего лишь "может быть".
Обоснуй. :)
На самом деле, рекомендации не бывают "зря", трудно угадать, что нужно конкретному человеку. Каждый воспринимает информацию по-своему. Кстати, imho "Психбольница" - это как раз о том, что называется usability.
А на блог Дениса Бескова (http://beskov.ru/2009/01/28/рекомендации-литературы-для-системн/), кстати, мог бы и ссылочку дать. Те книги, которые я рекомендовал, стоят в списке на первом и третьем месте. ("Книги и прочие источники перечисляются в порядке, рекомендованном к изучению.") На втором месте - ты будешь смеяться - Коберн. ;)
-
Хочу описать, что я вижу перед глазами и на что, в принципе, пока что ориентируюсь.
Мы разрабатываем софт. Есть заказчики, есть мы.
Заказчик сказал «я хочу, чтобы эта система складывала 5 и 6». Наш аналитик написал requirement на это дело, простенький такой, достаточно, документик. Даже без всяких UML обходятся. Отдал документ архитектору, который написал specification, где указал какие модули запускаются, какие процедуры вызываются. Отдал программисту, тот закодировал. Я – последнее звено цепочки, оттестировала. Вот у нас это выглядит так. Я много общаюсь с аналитиками, и поэтому прекрасно представляю, чем они занимаются. По крайней мере наши. А вот то, что пишут тут у вас, для меня пока что вообще очень мутно выглядит…
-
Нет, быть похожей на "наших" аналитиков я не хочу...Там из 5 человек трое "выросли" из переводчиков, одна из полусекретарши, один из программиста :)
Просто у меня с абстрактной теорией как-то неважно. Я пока на практике не увижу, не пойму как работает, в теории фигово получается разобраться. Потому я пока и не понимаю о чем у вас тут пишут. По всем данным ссылкам я обязательно схожу, как только в сознании туман хоть маленько прояснится с божьей (читаем "вашей") помощью :)
-
Ага! Еще один момент. Общение с заказчиком. Дело в том, что я не в России и язык этой страны пока что только учу. То есть говорить-то я на нем говорю, но весьма примитивно. Со временем будет лучше, но все равно, это не родной язык. Это может быть проблемой\препятствием?
-
Ага! Еще один момент. Общение с заказчиком. Дело в том, что я не в России и язык этой страны пока что только учу. То есть говорить-то я на нем говорю, но весьма примитивно. Со временем будет лучше, но все равно, это не родной язык. Это может быть проблемой\препятствием?
Может быть, конечно, так что учите язык. Но он, может быть, не очень сильно отличается от русского? :)
А вот английский вам точно необходим. В IT без него никак, независимо от рода занятий (если хотите расти, конечно), так что обязательно совершенствуйте и его.
А вот что было бы интересно: расскажите, как вообще обстоят дела с работой в сфере IT в той стране, в которой вы находитесь? Там много компаний, занимающихся разработкой программ? Как вообще поставлены процессы разработки (судя по короткому рассказу, их у вас есть - пять аналитиков это хорошо, у нас до сих пор многие компании не знают, что это за зверь такой - аналитик).
-
На самом деле их больше пяти :) Это просто те, с которыми я контактирую. Есть еще несколько...
Английский имеется. Не perfect, конечно, но advanced. Хотя вот уже несколько месяцев не использовала и забываться стал.
Местный язык от русского очень даже отличается, хоть и относится к славянской группе. Так что учить, учить не переучить.
С работой в сфере IT дела обстоят хорошо, айтишных контор много. Правда вот в связи с кризисом как-то все течет вяленько :)
-
Обоснуй. :)
На самом деле, рекомендации не бывают "зря", трудно угадать, что нужно конкретному человеку. Каждый воспринимает информацию по-своему. Кстати, imho "Психбольница" - это как раз о том, что называется usability.
А на блог Дениса Бескова (http://beskov.ru/2009/01/28/рекомендации-литературы-для-системн/), кстати, мог бы и ссылочку дать. Те книги, которые я рекомендовал, стоят в списке на первом и третьем месте. ("Книги и прочие источники перечисляются в порядке, рекомендованном к изучению.") На втором месте - ты будешь смеяться - Коберн. ;)
Не буду смеяться. С Денисом мы обсуждали какие книги стоит читать и почему.
По UML. После того, как вы научитесь писать требования UML вам может помочь писать более наглядно. А может и не помочь. Я почти всегда обхожусь без этих палочек и овалов. Просто не нужны.
Не все диаграммы UML относятся к разработке требований, а те что относятся:
* ВИ - альтернативный способ оглавления и только. Без требований бесполезны. См. Коберна. Есть - хорошо. Нет - наплевать.
* активности (и последовательности до кучи)- полезна в сложных случаях. На 1000 страниц требований хорошо если их будет 5 штук. Исключая системы со сложным взаимодействия подсистем (банкомат, SOA, ...)
* Состояний. Возьмем для примера такой продукт как Багзила. На все подробное описание страниц на 100-200 достаточно одной.
Что там еще к требованиям относится?
"Психбольницу" советовал исключительно потому, что человек интересуется юзабилити. В ней, в частности, описан интереснейший раздел требований "Архетипы". Помогает не только в разработке, но и в продвижении продукта.
-
Итак, имеем. Цель: попасть в ряды аналитиков (бизнес- или системных, я не определилась. Может быть, вы мне поможете? Позадаете наводящие вопросы, сделаете соответствующие выводы).
Если вы в МСК, то полезнее всего встретиться, если нет — то поговорить в Скайпе.
Учитывая, что мои вопросы могут быть интересны и остальным, задам их здесь.
Прежде всего стоит выяснить, нужна ли вам «аналитика».
1. Почему вы решили, что вам стоит попасть в аналитики? (А не в маркетологи, тренеры, руководители отдела поддержки и т.д.)
2. Чем, по вашему мнению, они занимаются?
3. Почему это круто?
4. Что в работе аналитика вам нравится больше всего?
Прочитала UML основы Фаулера, в процессе «UML. Руководство пользователя”
и «Разработка ИС с использованием UML».
Двигаюсь ли я в нужном направлении и что нужно делать дальше?
Нет, не двигаетесь. UML в работе аналитика вторичен, если не третичен.
Если аналитика вам действительно нужна, стоит прочитать 2 книжки и начать работать — хотя бы за бесплатно, стажёром-аналитиком, внутри своей организации или за её пределами.
-
Звучит все чрезмерно абстрактно. Как в университете на лекции было... Связи между этими лекциями и реальной жизнью я, правда, пока не увидела. Пригодилось мне только то, что делали на практических занятиях - те же самые модели баз данных, к примеру.
Так я же препод :) А потом пониматее есть такой Гегелевский закон - переход количества в качество. Без определенной суммы знаний и информации трудно что-то понять сразу. Однако процесс накопления вдруг переводит вас на другой уровень понимания...
-
Да... когда на третьем кажется курсе нам читали ООП, я скучала и думала - боже, какая хрень, куда ее, зачем ее, и вообще как могут люди сидеть и часами, днями, неделями писать код, да еще в этом ужасном Visual C++...
Золотые слова :)
В вузах надо начинать с объектно ориентированного подходи и UML? а потом переходить к программированию...
Я пока книжку по UML не взял и не прочитал про основы ООАП и не посмотрел это все на наглядных картинках, не мог понять что такое наследование и полиморфизм :)
-
Золотые слова :)
В вузах надо начинать с объектно ориентированного подходи и UML? а потом переходить к программированию...
Я пока книжку по UML не взял и не прочитал про основы ООАП и не посмотрел это все на наглядных картинках, не мог понять что такое наследование и полиморфизм :)
А я вообще четвёртое слово не помню. :) А третье, кажется, инкапсуляция.
ИМХО, это как раз тот случай, когда "наука" должна идти после "практики". Мне эти "принципы ООП" ни капельки не помогли, когда я с ним разбирался. А помогла какая-то тоненькая книжечка (названия уже не помню, что-то вроде "трудности ООП в C++"), содержащая несколько десятков примеров с объяснениями. Тем не менее, автор каждой книги по ООП, и по C++ в частности, почему-то считает своим долгом запихнуть эти "умные слова" в первую главу.
-
Прежде всего стоит выяснить, нужна ли вам «аналитика».
1. Почему вы решили, что вам стоит попасть в аналитики? (А не в маркетологи, тренеры, руководители отдела поддержки и т.д.)
2. Чем, по вашему мнению, они занимаются?
3. Почему это круто?
4. Что в работе аналитика вам нравится больше всего?
1. Потому что несмотря на мой технический бэкграунд программера, кодить мне совершенно не хочется. ИМХО, придумывать «как это будет» гораздо интереснее, нежели воплощать задумки в реальность, целыми днями гоняя код. Все, что указано в скобочках, меня вообще никак не касается и касаться не может.
2. Они переводят «хочу вот как-то так» заказчика в «будет так и так» для архитекторов и девелоперов
3. Я не знаю, что вы имели в виду под этим вопросом. Круто в чем? Круто для кого? Круто в какой области и по каким критериям?
4. То, что там работают мозги. В моей текущей работе они, например, вообще ни фига не работают. Ничего не придумывают, ни над чем не задумываются. Премерзкое ощущение, стоит отметить. А когда есть возможность из кучи информации выбрать главное и преподнести это в удобоперевариваемом виде, разве не есть это способ пошевелить извилинами как следует?
Многоуважаемый Денис, со встречей не получится, потому как я далековато от Москвы :) А вот в скайпе могу пообщаться только на выходных - в будни работа и учеба после работы, а когда все это кончается, у вас часов 12 будет ночи. Не очень удобно, наверное…
-
Первую книгу из списка начала читать. Книги прочитаю, разберусь, не проблема. Сложнее с должностью бесплатного стажера...В нашей компании им работать совершенно бессмысленно и безполезно, потому что я уже поведала, чем занимаются наши аналитики.
-
1. Потому что несмотря на мой технический бэкграунд программера, кодить мне совершенно не хочется. ИМХО, придумывать «как это будет» гораздо интереснее, нежели воплощать задумки в реальность, целыми днями гоняя код. Все, что указано в скобочках, меня вообще никак не касается и касаться не может.
Ок, принято. Хотя смущает формулировка про «как это будет».
2. Они переводят «хочу вот как-то так» заказчика в «будет так и так» для архитекторов и девелоперов
Что «будет так и так»? Бизнес-процесс, оргструктура, регламент, техническая архитектура системы, разбиение системы на бизнес-модули, порядок взаимодействия агентов, информационная архитектура интерфейса, концептуальное устройство интерфейса, архитектура ПО, структура БД, состав справочников, программные интерфейсы, алгоритмы, реализуемые в коде, аппаратная конфигурация, сетевые протоколы?
3. Я не знаю, что вы имели в виду под этим вопросом. Круто в чем? Круто для кого? Круто в какой области и по каким критериям?
Если вы хотите этим заниматься, значит вас должно от этого переть, если не прёт — то лучше не надо. Круто ли это для вас, прёт ли?
4. То, что там работают мозги. В моей текущей работе они, например, вообще ни фига не работают.
Ну это же не от профессии зависит. Мозги почти в любом месте могут работать.
А когда есть возможность из кучи информации выбрать главное и преподнести это в удобоперевариваемом виде, разве не есть это способ пошевелить извилинами как следует?
Ага! ) Вытащили ценность — вам нравится выделять главное, упрощать и доносить (делать доступным).
-
Сложнее с должностью бесплатного стажера...В нашей компании им работать совершенно бессмысленно и безполезно, потому что я уже поведала, чем занимаются наши аналитики.
Договоритесь с другой, найдите в своём городе профессионала-наставника и попроситесь к нему в стажёры.
-
Ок, принято. Хотя смущает формулировка про «как это будет».
Что «будет так и так»? Бизнес-процесс, оргструктура, регламент, техническая архитектура системы, разбиение системы на бизнес-модули, порядок взаимодействия агентов, информационная архитектура интерфейса, концептуальное устройство интерфейса, архитектура ПО, структура БД, состав справочников, программные интерфейсы, алгоритмы, реализуемые в коде, аппаратная конфигурация, сетевые протоколы?
А вот здесь я уже, думаю, встает вопрос о делении на системного аналитика и бизнес-аналитика, в ответе на который я просила помочь. Алгоритмы, реализуемые в коде, это ИМХО аналитика вообще ни коим образом не касается. Это даже архитектора не всегда касается…Аппаратная конфигурация и протоколы, это, по-моему, тоже к компетенции архитектора относится. Или накрайняк это относится к взаимодействию аналитика и архитектора. Но я, конечно же, могу ошибаться. Настолько широко я пока мыслить не умею…
Если вы хотите этим заниматься, значит вас должно от этого переть, если не прёт — то лучше не надо. Круто ли это для вас, прёт ли?
Не прет. Но от всего остального меня «прет» еще меньше :)
Ну это же не от профессии зависит. Мозги почти в любом месте могут работать.
Никто и не спорит. У дворника они тоже работают. Как подмести наибольшую площадь за наименьшее количество времени :D
Ага! ) Вытащили ценность — вам нравится выделять главное, упрощать и доносить (делать доступным).
Ну да, как-то так :)
-
Договоритесь с другой, найдите в своём городе профессионала-наставника и попроситесь к нему в стажёры.
Есть большая вероятность того, что в курс дела, в задачи проекта, в ход разработки меня никто посвящать не будет. Этот профессионал-наставник будет просто спихивать мне какую-нибудь рутинную работу в стиле «вот я тут требования набросал, ты их красивше напиши». Разве такая работа мне чем-то поможет развиться? Я понимаю, что совсем бесследно это не пройдет, но и толку особого не будет.
-
А вот здесь я уже, думаю, встает вопрос о делении на системного аналитика и бизнес-аналитика, в ответе на который я просила помочь. Алгоритмы, реализуемые в коде, это ИМХО аналитика вообще ни коим образом не касается. Это даже архитектора не всегда касается…Аппаратная конфигурация и протоколы, это, по-моему, тоже к компетенции архитектора относится. Или накрайняк это относится к взаимодействию аналитика и архитектора. Но я, конечно же, могу ошибаться. Настолько широко я пока мыслить не умею…
Ну вот и напишите, за какую часть решений «как будет» вам хотелось бы отвечать.
А впрочем, если не прёт — то лучше и не браться.
-
Есть большая вероятность того, что в курс дела, в задачи проекта, в ход разработки меня никто посвящать не будет. Этот профессионал-наставник будет просто спихивать мне какую-нибудь рутинную работу в стиле «вот я тут требования набросал, ты их красивше напиши». Разве такая работа мне чем-то поможет развиться? Я понимаю, что совсем бесследно это не пройдет, но и толку особого не будет.
Продолжайте сидеть на 5-й точке и оценивать вероятности.
-
Ну вот и напишите, за какую часть решений «как будет» вам хотелось бы отвечать.
А впрочем, если не прёт — то лучше и не браться.
Бизнес-процессы, разбиение системы на бизнес-модули, порядок взаимодействия агентов, структура БД, состав справочников, программные интерфейсы
Где-то вот здесь. По крайней мере с этим я хоть как-то сталкивалась во времена студенчества.
По поводу "прет" и "не прет" мне вообще постановка вопроса не нравится. Кого от работы прет, интересно? Нет, конечно, встречаются такие, но очень редко. Лично я, будь у меня возможность не работать, не работала бы. В мире много других более интересных вещей, чем работа. Но поскольку кушать все-таки хочется, то приходится что-то выбирать. И вот наименьшее отвращение из всего у меня вызывает представление себя в качестве аналитика (в том виде, в каком я пока что его себе представляю). Хотя книжечку, указанную Идой, погуглю.
-
Китайские мудрецы любят рассказывать такую притчу (а может и не притчу).
Когда ученик приходит к мастеру и просит того научить его своему искусству (кун-фу - не путать с китайскими единоборствами), то мастер сначала берет стакан и наполняет его до краев. Потом добавляет в полный стакан каплю, и вода выливается. Тогда мастер берет и выливает стакан, оставляя его пустым.
"Ученик. Ты видишь? Ты сейчас подобен полному стакану. Если ты хочешь, чтобы тебя научили, выплесни все, что ты до этого знал"
-
"Ученик. Ты видишь? Ты сейчас подобен полному стакану. Если ты хочешь, чтобы тебя научили, выплесни все, что ты до этого знал"
После этой фразы у моего любимого преподавателя бы случился инфаркт :-)
-
притчу я привел не к тому, чтобы преподы в инфаркте сваливались, а к тому, что очень часто старый опыт не позволяет принять новое. Потому и нужно от старого опыта избавиться
-
Не прет. Но от всего остального меня «прет» еще меньше
Думаю, у Вас недостаточное понимание о такой деятельности как разработка софта. Насколько Вы представляете себе всю технологическую производственную цепочку в этой области?
Почему Вы решили, что тот кусочек, которым Вы занимаетесь, неинтересен. Или из-за того, что в Ваши текущие задачи входит запускать тесты, придуманные и написанные другими людьми, и записывать их результаты (и опять же отдавать другим людям), Вы чувствуете себя бесполезной?
Ну так это не так. Вообще-то тестирование - довольно важный участок процесса разработки, который непосредственно влияет на качество итогового продукта, т.е. того, за что реально клиенты платят деньги.
И мозги там должны работать ничуть не хуже, чем у программистов и аналитиков с архитекторами.
Если Вам хватает опыта, то попробуйте сделать одно из следующих действий (или все)?
1. Попроситесь (причем сами - под лежачий камень вода не течет) принять участие в разработке тестов для следующей системы. Если Вас не возьмут, то уточните почему? Думаю, что много узнаете о возможных направлениях развития. Если возьмут, то практически сразу окунётесь в "результаты анализа" - будет возможность, поработав с этим, понять, что это такое и как с этим работать. Поймёте, разберётесь - будет возможность еще подрасти.
2. Попробуйте написать документ, типа, Программа и методика испытаний, или его часть. Представьте, что пишите курсовик по результатам предыдущей работы. Пишите для себя, но можно и показать кому-нибудь из коллег (тому, кто сможет реально оценить документ и дать советы, а не тому, кто может тупо присвоить Ваш труд).
3. Попробуйте систематизировать свой участок работы - тесты, чтобы снизить трудоемкость и повысить качество работы.
ну и так далее, в общем работайте над собой.
А может Вам турбизнесом каким-нить заняться или просто замуж выйти? Не думали над этим?
В любом случае, успехов.
Модератор: не надо писать фразы не относящиеся к теме.
2 Moder: насколько я прочитал исходное сообщение - человек просил наставить его на путь истинный. Зачем скрывать от него возможные альтернативы? :о))
-
А вы знаете процент людей, которые в восторге от своей работы? :)
У меня тяга к творчеству, рисованию, дизайну...Но к аналитике это не имеет никакого отношения. Давайте лучше по делу ;)
ошибаетесь, это есь широкий кругозор и именно это по сути ВСЁ математика, тоже что и анализ :)
типов специалистов два, или теоретик, или практик...тут уж кому что по душе.
теоретик строит модели, штудирует книжки, практик же проходит все в реальном поле...самое итересное поле это торговля-розница что не говори, если попадаешь в организацию с современными методами это хорошо, если можешь сломать руководителя на нацеленность в будущее - вообще супер...но пока в основном, читая вакансии, посещая компании, гнием прошлым если честно...вчерашним днем!
теоретик+практик вообще идеал...но это очень трудно найти думаю, или дорого, как мне думается.да и избыточно до жути...каждый деловойпроект имеет свой цикл, свой спрос, свою модель и свою реализацию.
-
типов специалистов два, или теоретик, или практик...тут уж кому что по душе.
в предложенной дихотомии, стоит добавить :) есть тысячи других :)
кроме того, есть гармоничные варианты
-
в предложенной дихотомии, стоит добавить :) есть тысячи других :)
кроме того, есть гармоничные варианты
ради встречи с гармоничными и приходится видеть тысячи других...
-
Здравствуйте. Я Константин. Не стал заводить отдельную тему, спрошу здесь.
Меня заинтересовала сфера аналитики, но я крайне слабо с ней знаком.
Расскажите, пожалуйста, чем занимается аналитик? Не общие задачи (целеполагание, управление и проч.), а вот по простым действиям :) Мне любопытно как выглядит "рутина", обычный рабочий день аналитика. Что он делает? Над решением каких проблем он думает? Много ли общения в работе? Такой вот "срез", если можно.
Про себя.
1. Почему вы решили, что вам стоит попасть в аналитики?
а. IT-образование
б. Склад ума, подход к решению проблем, жажда сделать все оптимально и эффективно. Особенно нравится приводить все в порядок и избавляться от лишнего.
в. Просто методом исключения. Пробовал уже себя в бизнесе, программировании, микроэлектронике да и многом другом.
г. Аналитика - в т.ч. отличная возможность НЕ работать по найму
д. Среди "Робеспьеров" (если вы котируете соционику) множество успешных аналитиков.
е. Интуиция подсказывает мне, что именно в аналитике я смогу раскрыть свой интеллектуальный потенциал (а других талантов у меня почти нет).
2. Чем, по вашему мнению, они занимаются?
Вот именно за ответом на этот вопрос я пришел на этот форум. Мне интересно узнать какова "рутина", обычный рабочий день аналитика. Что он делает?
3. Почему это круто?
а. Полная умственная самореализация.
б. Решать проблемы, а особенно эффективно решать - всегда круто. Мне вспоминается Винстон Вульф из Криминального Чтива, помните? Всегда нравился такой подход не только в работе, но и в жизни.
в. Всегда есть куда расти, "место для шага вперед"
г. Как мне кажется бизнес-аналитика (может ошибаюсь) находится на пересечении сфер IT и бизнеса. Причем она совмещает преимущества обеих сфер и исключает их недостатки. А бизнес и IT мне каждый по-своему интересны. Пожалуй наиболее интересны из всего земного в жизни :)
4. Что в работе аналитика вам нравится больше всего?
Не понимаю чем этот вопрос отличается от №3.
-
Божественно! Прикольный вопрос. Сейчас выдам опус, расскажу свою рутину, но как понимаете, это не инструкция к применению. Так что не обращайте внимания...нашло...
Работаю в банке, системным аналитиком.
10:00 Читаю письма Компании. Срочных нет, инцидентов нет. Система фурычит исправно. Значит читаю интернет, любимые сайты. Пью чай. Общаюсь с коллегами на предмет…как поспали, как дети, как отпуск. Особенно люблю слушать подвиги программистов, как они вчерась победили отчет или как оптимизировали вьюху.
10:30. Начинаю работать по задачам запланированных с вечера. Заметьте, предыдущие полчаса тоже считаю работой. Надо обязательно быть в курсе всех дел компании и личных дел коллег.
Ну а далее совсем не интересно, т.к. работа стандартна:
Проверка реализаций моих требований на предмет соответствия. Борюсь с программерами. Уже всех знаю наизусть, поэтому в зависимости от исполнителя… сначала смотрю код программы (ну если програмер не очень аккуратен или новичок), потом тестю (ну если програмер не внимателен, то куча ошибок), проверяю реализацию функционала (если програмер имеет очень много своего мнения и рвется к вершине, то всегда сделает как он хочет). Ну в зависимости от всего этого и мои действия. Кого поправить, кого направить, а кому и показать кто в доме хозяин (ну типа напомнить, кто сдает требования бизнесу). Передаю бизнесу.
Анализирую бизнес требования. Пишу ФТТ. Это всегда интересно. Мозги кипят, и охватывает гордость, когда я смогла красиво вписать требования, реализовывая минимум кода. И уныние, когда я не всегда владею знаниями бизнеса. Тогда я не стесняясь звоню/пишу заказчику и прошу пояснить. На нынешней работе все всегда с удовольствием рассказывают. Когда я работала в компании-разработчике ПО, то заказчик (обычно банк) в 50% намекал мне какая я все-таки необразованная и не знаю таких «простых» вещей. Приходилось проглатывать такую пилюлю. Ну еще большее уныние, когда я не знаю, как вписать в систему новые требования. Система сложная, все знать нереально, найти консультанта практически невозможно. Поэтому приходиться лопатить кучу кода, что бы все-таки решить задачу. Тут я откровенно потею. Не всегда удается. За последний год, пару раз не смогла и пришлось обращаться в компанию по разработке ПО ;(
Еще консультирую всех подряд на предмет того, можно ли реализовать это в системе и как грамотно написать бизнес требования; сколько займет времени реализация того или иного требования; как сделать быстро и дешево; как повысить приоритет задачи; когда реально это запустить; как протестировать функционал; как реализовать это в коде; что вообще надо делать и с чего начать, что бы это все- таки поехало :); ну и т.д. в этом духе. Это все делается либо по телефону, либо на митингах, либо письмами.
16:00 Обед, прогулка по городу. Теперь люблю одна. За день так хочется помолчать и просто подумать. Часто за время обеда ко мне приходят умные мысли и я быстро возвращаюсь и пишу…пишу…пишу.. Но иногда я позволяю себе «обедать» пару часов.
19:00 Ура! Домой. Пишу план на завтра. Звонок манагера: «Так срочно надо, если к утру не сделаем, меня порвут на грелку. Извини весь спринт поехал.». Возвращаюсь, делаем…Не монстр же я какой-нибудь. Но завтра я уйду после обеда…Мечтаю.
-
Здравствуйте. Я Константин. Не стал заводить отдельную тему, спрошу здесь.
Меня заинтересовала сфера аналитики, но я крайне слабо с ней знаком.
Расскажите, пожалуйста, чем занимается аналитик? Не общие задачи (целеполагание, управление и проч.), а вот по простым действиям :) Мне любопытно как выглядит "рутина", обычный рабочий день аналитика. Что он делает? Над решением каких проблем он думает? Много ли общения в работе? Такой вот "срез", если можно.
зачем быть аналитиком-то? столько вакансий начальников чего-либо (вплоть до ген.директора)
-
зачем быть аналитиком-то? столько вакансий начальников чего-либо (вплоть до ген.директора)
Общение с людьми - не мой конек. Недостаточно коммуникабелен. Нет навыка убеждения, лидерских качеств. В работе начальника слишком много общения.
Elf
Спасибо огромное. Интересно.
-
Общение с людьми - не мой конек. Недостаточно коммуникабелен. Нет навыка убеждения, лидерских качеств. В работе начальника слишком много общения.
Имхо, работа аналитика очень зависит от коммуникаций. Если вы не сможете налаживать контакт с нужными людьми, то результаты Вашего труда будут неудовлетворительными как бы качественно Вы не подходили к работе.
Работа аналитика в любом случае связана с общением:
- общаетесь с заказчиком, пытаетесь домыслить, что ему надо
- систематизируете то, что усвоили, советуясь или уточняя
- доносите до проектной команды видение свое и заказчика
На любом из этапов может возникнуть конфликт или недопонимание, которое обязательно надо выявить и устранить, иначе проект рискует стать неуспешным (убыточным, сданным не в срок или не сответствовать ожиданиям заказчика).
С другой стороны, если вы подтянете свой навык до приемлемого, то можно вполне успешно работать, главное не забывать, что коммуникации - "главное и основное" ©
-
Общение с людьми - не мой конек. Недостаточно коммуникабелен. Нет навыка убеждения, лидерских качеств. В работе начальника слишком много общения.
думаете, аналитик сидит затворником? откуда он по-вашему информацию собирает?
в таком случае лучше кочегаром быть или лесником где-нить в глуши
-
Действительно, аналитик общается с людьми больше всех в команде, за исключением разве что менеджера проекта, да и то как повезет.
Когда я был новорожденным аналитиком, я думал что самое главное - это круто рисовать схемы на UML да знать нотации BPMN с IDEF.:)
Однако практика работы показала(сейчас говорю только за себя конечно), что самое главное - это вытянуть из заказчика то, что ему действительно нужно, а не записать в ТЗ то, о чем он говорит.
Что нужно разрешать конфликты требований между представителями заказчика.
Что нужно следить за разработчиками чтобы они делали по ТЗ.
Что нужно помогать тестерам при проверке требований.
Что основные инструменты аналитика - это не Requisite Pro, Sparx EA и BPWin, а почта, телефон и Word:)
Работа аналитика неразрывно связана с общением.
Если вы не любите разговаривать с людьми, то лучше даже не пытаться. Потому что придется каждый день с ними общаться. От соседа-разработчика, до директора Банка. И к каждому нужен свой подход.
-
Коллеги , Осталось два дня чтобы успеть записаться на Сертифицированный курс по управлению требованиями. (IREB)
К сожалению до нас только сейчас дошло что этот курс идеальная возможность для тех кто имеет знание английского языка и ИТ для того чтобы начать карьеру аналитика.
Если у Вас есть друзья или ребята в компании которые могут быть в этом заинтересованы поделитесь с ними этой ссылкой . Спасибо !
http://www.system-approach.ru/edu/requirements-engineering-ru/
-
Долго обдумывал и, дабы не плодить тем, задам вопрос прямо в этой ветке.
Некоторое время тому назад очень заинтересовался профессией бизнес-аналитика. Почитал литературу и понял, что в итоге хочу вырасти именно в БА (а не в СА, ибо IT-бэкграунда маловато, да и вообще - пока оное не представляется мне столь интересным).
Проблема в том, что у меня совершенно непрофильное образование. Мало того, что гуманитарий, так еще и музыкант. Но, после изучения BABOK по диагонали (а заодно и Business Analysis Competency Model), понял, что еще не всё потеряно: за годы работы по своему профилю, а так же на разных других низкооплачиваемых должностях, накопилось достаточное количество личностнх качеств, знаний, которые вполне могу мне помочь в достижении цели.
В настоящее время активно начитываю BABOK (и, если раньше мне в нем виделось много воды, то сейчас понимаю - наоборот, там всё очень конкретно и по делу), знакомлюсь с литературой по Теории Ограничений (книга Детмера - изумительная, логичная и понятная), пытаюсь хоть немного разобраться с понятием Use-case (кстати, до сих пор не вкурил - посоветуйте литературу, пожалуйста), и прочее. Словом, за неимением практики пытаюсь пополнить теоретический багаж.
Вопрос состоит в следующем: что мне нужно, в итоге, знать и уметь? Цель: устроится в Петербурге на должность младшего аналитика, либо стажера. Если честно, я в затруднении. Не могу выстроить для себя план развития, определиться с приоритетами.
"Я знаю, что ничего не знаю" (приписывается Сократу).
P.S. Во вложении - резюме, которое попытался составить на HeadHunter. Буду благодарен, если отдельно покритикуете так же и резюме. Заранее благодарю.
-
Вопрос состоит в следующем: что мне нужно, в итоге, знать и уметь?
В Вашем опусе Вы же уже и ответили на вопрос - набрался теории, теперь нужна практика, ищу работу стажера.
-
<...> Цель: устроится в Петербурге на должность младьшего аналитика, либо стажера. Если честно, я в затруднении. Не могу выстроить для себя план развития, определиться с приоритетами.
Подсказать селект для ХэдХантера ?
Бо под лежачего инженера коньяк не течет.
Как-то так:
(((систем*) or (бизнес*)) аналитик) and ((1) or (2) or (3)) not ((4) or (5) or (6))
1..3 (можно больше или меньше) - заполняете областями народного хозяйства, в которых хоте ли бы на работать, к примеру ((розн*) or (логист*))
4..6 (можно больше или меньше) - соответственно где не хотели бы, к примеру ((банк*) or (финанс*))
...
можно добавить еще блок AND с изученными скилами типа "and ((BPM*) or (IDEF*))", в Вашем случае "and BABOK", но это уменьшит выборку - многие работодатели копипастят чужие вакансии не глядя на их содержание и суть.
Use-case (кстати, до сих пор не вкурил - посоветуйте литературу, пожалуйста), и прочее. Словом, за неимением практики пытаюсь пополнить теоретический багаж.
Стоит почитать в любом случае:
К.Вигерс "Разработка требований к программному обеспечению"
А.Перерва, В.Иванова "Путь аналитика. Практическое руководство IT-специалиста"
Обе книги можно официально купить в электронном виде (Литрес и Питер соответственно), что радует.
Собственно Варианты использования:
Элистер Кокбёрн "Современные методы описания функциональных требований к системам"
Читать лучше в подлиннике (Writing Effective Use Cases by Alistair Cockburn - на Литресе есть в ePub, дороже чем бумажная) если хватает знаний английского. Перевод - жуткий, можно вешаться сразу. Но суть и простейшие методы можно уловить и по переводу.
и в качестве PS
"Младший" пишется без мягкого знака.
Русский язык - это главный инструмент аналитика, даже младшего.
-
"Организация как система" Генри Нив
-
...
и в качестве PS
"Младший" пишется без мягкого знака.
Благодарю за ответ. И да, кошмарная опечатка, спасибо, исправил. :-)
За Вигерса отдельное спасибо. Он у меня был отложен к прочтению, в библиотечке, но никак не решался ознакомиться. А тут открыл, решил пробежать хотя бы по-диагонали и понял: Это именно то, что мне нужно.
По юзккйсам - ознакомлюсь, спасибо. А Yakobson'а - "Use-Case 2.0" читали? Впечатления?
"Организация как система" Генри Нив
Спасибо. А что еще по теории систем и по системному анализу посоветуете?
-
Благодарю за ответ. И да, кошмарная опечатка, спасибо, исправил. :-)
Зря иронизируете, если честно. Программистам я могу простить ошибки в русском, мне важнее чтобы они не ошибались в PL/SQL и ABAP. Но когда консультант (тоже аналитик, если не бороться за термины) приносит документ (то есть один из основных продуктов своей деятельности), набранный в Ворде с ошибками .... ну не могу я уже дальше воспринимать его серьезно.
И у меня есть стойкое ощущение, что я не один такой.
По юзккйсам - ознакомлюсь, спасибо. А Yakobson'а - "Use-Case 2.0" читали? Впечатления?
Я - нет.
Да и не видел такой книги, если честно. У Якобсона есть мегабиблия по UML-2, разработчиком которого он и является. Полагаю, Вы именно этот труд имеете в виду.
О юз-кейсах книг как таковых написано не так и много. Но. Кокбёрн - грамотный методолог, его достаточно. Дальше уже идет агиле, скрюм и хрю. Там другие книги.
Я прочитал Кокбёрна, заинтересовался, покопался в интернете, нашел несколько примеров. Сделал пару шаблонов документов и описал юз-кейсами на пробу небольшую задачку (параллельно с "обычным" документированием), дал на сравнение пользователям и разработчикам (параллельно разъяснил что к чему). Особого энтузиазма не увидел. Отложил.
Но это касается только моей работы, в другом месте могло бы быть иначе, тут применимость от привычек зависит.
Конкретно в этом случае есть ещё момент, тормозящий самостоятельное изучение. Мало-мальски серьезный проект с описанием юз-кейсами абсолютно немыслим без полноценного ПО для Управления Требованиями. А оно всё денег стоит и немалых. Я в своей песочнице использовал самописку на Access, но это не серьезно в полноценной работе.
Спасибо. А что еще по теории систем и по системному анализу посоветуете?
Из Теории - Практику :)))
Владимир, попытки прочитать всю мировую литературу по одной теме - это манчкинство чистой воды. Хотя бы потому, что именно в теоретической части они будут очень сильно .... коррелировать, назовем это так.
Для примера.
Есть такая область человеческой деятельности, как управление процессами.
Есть книга Владимира Репина "Бизнес-процессы. Моделирование, внедрение, управление"
Есть курс SAP BPM300 "Business Process Management Governance"
Так вот первые 2/3 этих немалых талмудов совпадают практически полностью - вплоть до картинок. Разница начинается в практической части, где Репин дает примеры в Business Studio, а SAP ожидаемо в NetWeaver.
Наилучший цикл самообучения на мой (и не только) взгляд:
Чтение вводного букваря "для чайников"
Практика на простеньких задачах, накопление вопросов.
Поиск ответов на вопросы, более глубокое изучение предмета.
Практика на реальных задачах.
...
...
Написание собственного букваря и/или преподавание на курсах.
До последнего этапа мало кто доходит. Большинство останавливается там, где у меня начались многоточия. И нормально, не жалуются.
Читайте 2-3 книги и начинайте.
Если есть время и желание учиться - лучше параллельно уделите внимание другим прикладным областям.
- Возьмите Уокенбаха, подучите Excel до нормального уровня
- Возьмите книги серии "Шаг за шагом" по Word и Visio.
Изучите их хотя бы до свободного, без посторонней помощи, прохождения простенькой сертификации на RetraTech
- Посмотрите хотя бы пару популярных нотаций моделирования.
Больше пользы будет.
Вот честное слово, мне на работе намного ценнее консультант/аналитик, который может быть не знает всех глубин теории, но может написать внятную (и кстати, что немаловажно, стилистически приятную и читаемую, без целых абзацев 12-м полужирным курсивным Эриалом) спецификацию, а затем на тесте собрать данные и проанализировать корректность работы. В данном случае умение пользоваться ВПР и сводными таблицами не менее важно, чем знание наизусть всех книг по теории.
P.S.
Вот как сейчас придут сюда местные ГУРУ, как погонят нас из закрепленной темы :)))
Вон в соседней уже выражают недовольство :)))))
-
И тут Остапа понесло.
Есть минимум еще одна книга, без которой аналитик будет подобен флюсу © К.Прутков.
С.Канер, Д.Фолк, Е.Нгуен "Тестирование программного обеспечения"
Отлично прочищает кстати. Не всем правда. Требования вида "обеспечить удобный пользовательский интерфейс" - это не так себе прикол, а вполне себе реальность.
... Всё, удалился.
-
Могу посоветовать посетить какие-нибудь специализированные курсы практической направленности, например http://school.system-analysis.ru/kak-pisat-tz/ (http://school.system-analysis.ru/kak-pisat-tz/), или другие, информация о них время от времени появляется на данном форуме. Такие курсы помогают, как минимум на начальном уровне, соотнести теоретические знания с тем как их надо применять.
-
Андрей, благодарю за столь развернутый ответ.
Вы помогли мне определиться с дальнейшими векторами развития. Обязательно воспользуюсь вашими рекомендациями. Пока что запланировал для себя уложить в голове литературу, которую уже начал читать: BABOK, Вигерс, Детмер (по Теории Ограничений), Кокберн, Уокенбах (или еще что-нибудь по Excel), что-то еще по бизнес-анализу в целом (Podeswa понравился, пишет доходчиво), что-нибудь по UML / BPMN. Затем буду практиковаться на искусственных задачах (или в приложении к своей жизни, как иногда советуют). А там видно будет.
По поводу личной грамотности - ни в коей мере не иронизировал. Сам считаю, что подобные ошибки недопустимы в деловой переписке и потому всегда внимательно вычитываю текст перед публикации. Но вот, увы, был невнимателен.
Что касается Якобсона, то я подразумевал именно книжку под названием "Use-Case 2.0", опубликована в 2011 году (на английском). Могу куда-нибудь залить, если интересно. Сам столкнулся, что литературы по юзкейсам мало. В общих чертах (и благодаря этой книге) смысл понял так: это истории, к которых кто-то взаимодействует с чем-то и, при этом, совершает какие-то действия. Правильно? Но у Якобсона, к примеру, именно концептуально всё описано, абстрагированно от конкретных приложений. А мне на текущем этапе хотелось бы более конкретно: как именно писать Use-Case'ы, какими средствами, "правильные" способы, методика и прочее в том же ключе.
P.S. А вообще, реально развиваться в бизнес-анализе, не прокачивая свой скилл в IT? Потому что очень много говорят о разработке ПО, тот же Вигерс - он же рассказывает исключительно о требованиях к ПО. Какое практическое применение эта книга может иметь за пределами этого домена? У меня, наверное, в мозгах всё еще некоторый сумбур, в каких-то вещах заблуждаюсь.
Могу посоветовать посетить какие-нибудь специализированные курсы практической направленности
Не вижу смысла на данном этапе. Имхо, курсы хороши, если уже начал где-то работать и надо повысить уровень своих компетенций в конкретной области. А иначе - необоснованная трата денег. Нет? :)
Осознал одну очень важную штуку: необходимо очень хорошо знать английский язык. Поэтому, если и будут какие-то запланированные затраты на обучение в ближайшее время, то первое, что сделаю - запишусь на хороший курс английского языка у себя в Петербурге.
-
del
-
Смотря какие курсы СА. Знаю, случай и не один, когда студенты случайно попадали на курсы всемиуважаемых профессионалов :) - заинтересовались системным анализом и после ВуЗа устраивались аналитиками. Но опять же это МСК.
ИТ скил для системного анализа предпочтительнее. Т.к. уже в тех ВУЗе есть много курсов связанных с разработкой ПО, там их учат писать документацию, обучают этапам проектирования и др. Но если есть упорство и везение - можно и без техзнаний стать аналитиком. Особенно бизнес аналитиком. Здесь главное найти предметную область. Например, если экономист/финансист, то можно попытаться найти работу БА в банке/фин.компании.
Англ яз. нужен. Но развивать его лучше не курсами, а практикой.
-
Могу порекомендовать еще одно направление развития. Как по мне - самое эффективное, но и самое труднодостижимое.
А именно, всеми правдами и неправдами набейтесь в подмастерья к практикующему аналитику выше среднего уровня. Попросите объяснить, научить, проконтролировать в первых (и последующих) шагах, поправить и направить. Собственно, всё.
На мой взгляд, Вы несколько переоцениваете значимость английского. Мне, например (да и окружающим коллегам на нескольких последних местах работы), именно по существу работы он не нужен. Полезен скорее для собственного развлечения, почитать разное. Но у меня специализация - госструктуры. В бизнес-проектах он, возможно, нужнее.
Не советую также с головой уходить в детали описания инструментария в умных книжках (того же UML или BPMN). Без должной практики и/или ИТ-базы это будет не в коня корм. Потом успеете. Если вы целите в бизнес-аналитику, почитайте больше об устройстве "бизнеса". Коллега SALar, к примеру, дельный совет дал. Почитайте, какие системные сложности есть в организациях разной природы, как с ними справляются при помощи ИТ-решений. Какие это решения.
Что касается опасений насчет недостатка бэкграунда - особо не переживайте. Он весьма полезен, но на моей памяти отлично трудились ведущим бизнес-аналитиком врач-психиатр, а системным архитектором - врач-биохимик. Причем не только по диплому, но и с некоторой практикой за плечами. Бэкграунд - дело наживное.
-
Могу порекомендовать еще одно направление развития. Как по мне - самое эффективное, но и самое труднодостижимое.
А именно, всеми правдами и неправдами набейтесь в подмастерья к практикующему аналитику выше среднего уровня. Попросите объяснить, научить, проконтролировать в первых (и последующих) шагах, поправить и направить. Собственно, всё.
+1
Уж насколько плохо четвертое правило воронки, но самостоятельное изучение еще хуже.
Будете трактовать закон гравитации как в "Пасынках вселенной" Хайнлайна.
-
Внимательно перечитала сегодня эту тему и сделала для себя такой вывод:
Сообщество профессиональных аналитиков это агрессивно настроенная к новичкам, скептически настроенная к миру в целом, шизоидная и невротичная среда.
Бррр!!!! ((((( Не ходите дети в ООА гулять.
-
Решайте задачи разные и много