Ищем стажёра бизнес-аналитика (частичная занятость, договор ГПХ, 20 000 руб/мес)
О проекте
IT-проект в начальной фазе разработке. Мы ищем стажёра-бизнес-аналитика, который поможет команде с анализом требований. Обучим необходимым навыкам (BMPL, UML, C4 и т.д.).
Задачи
— анализ ТЗ заказчика и описание требований;
— документирование бизнес-процессов;
— проектирование SQL-базы данных;
— подготовка отчётов;
— участие в тестировании функций продукта.
Требования
— общее понимание ИТ;
— базовые знания SQL (select, join, group by);
— понимание основ бизнес-анализа;
— желание учиться и развиваться;
— аккуратность и ответственность.
Условия
— удалённая работа;
— 15–20 часов в неделю, гибкий график;
— договор ГПХ;
— вознаграждение — 20 000 руб/мес;
— вы получите опыт в реальном проекте + рекомендация по итогам.
Здравствуйте, gyraboo, Вы писали:
G>Ищем стажёра бизнес-аналитика (частичная занятость, договор ГПХ, 20 000 руб/мес)
G>О проекте G>IT-проект в начальной фазе разработке. Мы ищем стажёра-бизнес-аналитика, который поможет команде с анализом требований. Обучим необходимым навыкам (BMPL, UML, C4 и т.д.).
$200 за работу на полставки — не ошибка? Это же зарплата за полдня, а не за полмесяца?
Безотносительно вакансии, просто интересно. BPML, UML — как вы этим пользуетесь?
В смысле "рисуете квадратики", или на самом деле следуете этим спецификациям?
Здравствуйте, bnk, Вы писали:
G>>Ищем стажёра бизнес-аналитика (частичная занятость, договор ГПХ, 20 000 руб/мес) bnk>$200 за работу на полставки — не ошибка? Это же зарплата за полдня, а не за полмесяца?
Для стажера, кто не имел опыта в аналитике и хочет на парт-тайме, чтобы мы его ещё и научили — разве это мало? Это ниша мелких частных проектов, это не высокобюджетные коммерческие проекты.
bnk>Безотносительно вакансии, просто интересно. BPML, UML — как вы этим пользуетесь? bnk>В смысле "рисуете квадратики", или на самом деле следуете этим спецификациям?
Если BMPL нарисован удачно и описывает весь бизнес-процесс, он вообще является исполняемым. И каждый прогон (экземпляр) процесса можно трекать каждый пройденный шаг, смотреть статистику, хот-поинты, назначать ручные задачи на узлы и т.д. Например, такой функционал есть в Камунде. Если у тебя сложный бизнес-процесс, то есть несколько вариантов реализации:
1. Хореография (т.е. набор сервисов, каждый сервис вызывает следующий в цепочке, но общая картина по цепочкам и по логическому виду процессов с "высоты птичьего полета" размывается)
2. В виде машины состояний (типа Spring State Machine)
3. Rules engine тип Drools
4. Оркестрация в виде исполняемого BPMN-процесса камунды (этот вариант мне нравится больше других, т.к. у нас сразу есть и визуальная диаграмма и редактор для неё, и она же является исполняемой, т.е. является оркестратором, и мы видим весь процесс с высоты птиьчего полета целиком, а не фрагментарно, как в хореографии)
Здравствуйте, gyraboo, Вы писали:
G>Для стажера, кто не имел опыта в аналитике и хочет на парт-тайме, чтобы мы его ещё и научили — разве это мало? Это ниша мелких частных проектов, это не высокобюджетные коммерческие проекты.
Вопрос, насколько востребовано на рынке то, чему они научат. Бум UML и иже с ними был два десятка лет назад. Потом, ВНЕЗАПНО, выяснилось, что сложность не в рисовании квадратиков, а в эффективной коммуникации с десятком человек с разным видением, чего им нужно от конечной системы. И квадратики как-то резко сошли на нет.
G>Если BMPL нарисован удачно и описывает весь бизнес-процесс, он вообще является исполняемым. И каждый прогон (экземпляр) процесса можно трекать каждый пройденный шаг, смотреть статистику, хот-поинты, назначать ручные задачи на узлы и т.д. Например, такой функционал есть в Камунде. Если у тебя сложный бизнес-процесс, то есть несколько вариантов реализации:
Ага, и это все офигенно нужно для мелких частных проектов. Попахивает местячковым карго-культом энтерпрайза, без понимания, для чего это вообще нужно. Еще и с серым оформлением, по которому стажера можно кормить завтраками на тему "заплатим, как все дорисуешь".
Стажёру нетрудно устроиться на полную ставку тыщ на 100 и по ТК.
А вот это вот подразумевает очень хорошие знания СУБД, а также неплохие знания (или возможность выделить значительное время на изучение) предметной области заказчика:
G> — анализ ТЗ заказчика и описание требований; G> — документирование бизнес-процессов; G> — проектирование SQL-базы данных;
Понимаю, что в конкретном смысле то, что я пишу, полный оффтопик. Я же не откликаюсь на вакансию и не предлагаю конкретную кандидатуру.
Вместе с тем, с другой стороны, это а) интересно и б) абсолютно по теме не в конкретном, а в более абстрактном аспекте.
Я по тематике описанной вами вакансии какое-то время назад создал тему, в которой написал, что ничего в такой работе как раз не понимаю и никогда не мог понять, как бы ни пытался.
Вот данная тема: http://rsdn.org/forum/education/8512283.flat
Если будет время и желание, было бы интересно прочесть ваш ответ там.
Плюс, это может пригодиться вам для работы вот в каком смысле (если это не моё дело, сразу извините, и я ухожу).
Вот вы описали вакансию. Перечислили требования, обязанности, что человек должен знать.
То есть, знать должен — соискатель и работник. И эти вопросы о том, владеет ли он этим, пусть докажет, как он сам понимает перечисленные пункты — написанные вами вопросы к нему, к работнику.
С другой стороны!!! Давать поручения будете вы. Соискателю, имеющему какие-то знания и способности, может быть интересно, а как вы сами понимаете те же вопросы и ту же сферу, по которой спрашиваете.
Он-то знает что-то, но его будущий коллега может знать и представлять себе по-другому.
Поэтому, в принципе, в определённой мере интересно узнать представления или хотя бы периметр этих представлений по тем же темам у такого будущего коллеги, у работодателя.
Вы даёте вакансию в этой сфере. Значит, сами её понимаете, работаете в ней и несёте ответственность за эти знания. Поэтому лично мне интересно.
Но я не настаиваю на ответе. Я вообще могу сказать, что за много лет на эти вопросы мне отвечать работающие в этой сфере люди отказывались. Я ничего себе не прояснил, как и рассказал там.
Здравствуйте, Marzec19, Вы писали:
M>Вы даёте вакансию в этой сфере. Значит, сами её понимаете, работаете в ней и несёте ответственность за эти знания. Поэтому лично мне интересно. M>Но я не настаиваю на ответе. Я вообще могу сказать, что за много лет на эти вопросы мне отвечать работающие в этой сфере люди отказывались. Я ничего себе не прояснил, как и рассказал там.
Указанные тобою там темы не относятся к аналитике (а моя вакансия именно по аналитике):
"научный менеджмент"
"системный анализ"
"управление проектами"
"системное проектирование"
"управление бизнес-процессами"
Но своё мнение выскажу: успешное управление проектами — это работа на стыке фундаментальных менеджерских стандартов (например, по PMBOK, антикризисное управление, риск-менеджмент), живых практик в успешных ИТ-компаниях и серьёзных личных качеств.
1. Фундаментальные знания прокачиваются по соотв. книгам. Просто начни читать про риск-менеджмент, антикриз в проектном управлении, изучи БОКи (PMBOK, CBOK), читай книги по Kanban, Agile, по водопадной модели, по деловой коммуникации тоже не помешает (например, есть хорошая книга Барбара Минто "Принципы пирамиды").
2. Живая практика изучается на местах. Устраивайся в успешные ИТ-компании, работай там по 2-3 года, наблюдай, как там строится управление проектами.
3. Личные качества прокачиваются и с ментором, и на курсах (например, актерское мастерство, публичные выступления, можно участвовать в любительском театре).
Чтобы войти в управление проектами, если нет природных данных — это весьма трудная задача, но, думаю, выполнимая.
По теме же моего топика (аналитик-стажёр) мы даём ряд книг (методичек), и ждём, чтобы человек их освоил до собеса или на период испытательного срока, чтобы был общий язык и общая понятийная база.
Вот ряд этих книг:
Брюс Сильвер "BPMN Метод и стиль" (практика по использованию BPMN)
Фёдоров "Моделирование бизнес-процессов в нотации BPMN 2.0"
Мацяшек "Анализ требований и проектирования систем" (книга по UML-практикам, скорее для общего развития и чтобы аналитик понимал программистов, а вообще в современной аналитике UML применяется редко, BPMN гораздо лучше решает эту задачу)
BABOK 3.0 (свод международных практики по аналитике)
Обзорная книга Вадима Алджанова "ИТ-архитектура. Теоретические основы" (TOGAF, ITIL, PMI, CobiT) — для общего развития
"Методичка ERD" части 1-2 (АКАДЕМИЯ БЮДЖЕТА И КАЗНАЧЕЙСТВА) (практика по ER-диаграммам и проектированию реляционной модели данных — эти знания и умения обязательны для аналитика)
Эти книги дают общую фундаментальную базу, и чётко дают понять, какие именно именно знания и навыки мы ждём от аналитика. А не "сделай то, не знаю что".
Здравствуйте, gyraboo, Вы писали:
G>Указанные тобою там темы не относятся к аналитике (а моя вакансия именно по аналитике):
Аналитик — это и есть системный анализ?
Или чем отличается?
Спасибо за интересный ответ. Наиболее интересное для меня в нём — идея "аналитик — это не относится к научному менеджменту и системному анализу".
Данное непонимание как раз и подтверждает то, что я там написал — полное непониимание темы и в очередной раз неспосбность понять, выраженная другими словами, но по-моему, очень ярко и конкретно.
Здравствуйте, Marzec19, Вы писали:
M>Аналитик — это и есть системный анализ? M>Или чем отличается?
Системный анализ — это общая дисциплина. Она точно не помешает и ИТ-архитектору, и менеджеру проектов, и аналитику.
Овладев системным анализом, ты сможешь видеть и исправлять системные проблемы, а не просто заниматься "тушением пожаров".
Если ты управляешь проектом без учёта системного анализа, то в какой-то момент сложность проекта и кодовой базы достигает критической точки, после которой дальнейшее развитие проекта невозможно, сдача стабильных релизов невозможна (например, проект входит в регрессионный ад: "одну фичу делаем — две старые ломаем").
Чтобы управлять сложным проектом, нужно делать это системно.
Системный анализ даёт некую фундаментальную базу для этого.
Но одного системного анализа недостаточно, см. выше, я перечислил, что ещё нужно.
А аналитик — это человек, который обычно общается и с бизнесом (выявляет потребности бизнеса, проводит интервью, рисует BPM-диаграмым, делает ТЗ для разработчиков) и с разработчиками, служит мостиком между ними. Аналитик должен иметь хорошие коммуникативные навыки, или данные ему от природы, или прокачанные. И он должен любить общаться. Если аналитик не любит и не умеет общаться, находить общий язык с людьми разных психиатрических психологических укладов, грош ему цена.
M>Спасибо за интересный ответ. Наиболее интересное для меня в нём — идея "аналитик — это не относится к научному менеджменту и системному анализу".
Аналитик частично пересекается с системным анализом и с научным менеджментом.
Знание научного менеджмента само по себе не является серебрянной пулей. Ну, допустим, знаешь ты опционную модель рисков, или умеешь строить портрет кризиса и антикризисный план, но не имея развитых коммуникативных навыков, ты не сможешь внедрить никакую научную практику, потому что умение договариваться — без этого ИТ-менеджеру будет трудно. Ну и умение адекватно оценивать необходимость внедрения конкретных практик научного менеджмента — тоже обязательно. Просто придти в компанию и просто тупо начать "внедрять научный менеджмент" — это не сработает.
