Форум Сообщества Аналитиков
Дисциплины => Обучение => Конференции Семинары и Тренинги => Тема начата: bas от 30 Октября 2008, 00:38:54
-
Хочу подготовить связанную серию бесплатных семинаров, но не знаю какой лучше взять вектор. Есть 2 варианта:
1. Двигаться вдоль методологии разработки ПО
1.1. Общий обзор методологий и роли Аналитика в процессе разработки ПО
1.2. Бизнес анализ. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, какие готовятся артефакты, как моделировать БП и БО и зачем это нужно
1.3. Системный анализ + Требования. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, как моделировать требования к ПО и зачем это нужно
1.4. Проектирование. Рассказать что Аналитик делает в данной дисциплине, зачем нужна данная дисциплина, как моделировать архитектуру ПО и зачем это нужно
1.5. Разработка+Тестирование+Внедрение. Что делает Аналитик в этих дисциплинах и как используется здесь документы Аналитика
1.6. Управление изменениями. Как правильно управлять изменениями с т.з. Требований
1.7. Управление проектом (УП). Что Аналитик должен знать про УП и как он работает в проектной команде
1.8. ПО Аналитика. Обзор необходимого ПО Аналитика.
+Примеры
2. Двигаться вдоль дисциплины управления требованиями
1.1. Общий обзор требований и роли Аналитика
1.2. Сбор требований. Зачем, как нужно и как не нужно
1.3. Анализ требований.
1.4. Документирование требований
1.5. Моделирование требований.
1.6. Проверка требований.
1.7. Изменение требований
1.8. Требования в различных дисциплинах разработки ПО (БА, СА, Проектирование, ....)
+ Примеры
Что бы Вам было более интересно?
-
Саш, мне все интересно. За оба направления проголосовать можно?
-
Если я все правильно понял, то пункт 2 является декомпозицией пункта 1.3.
Так вот наиболее интересно мне было бы узнать о всех пунктах варианта 1 на уровне варианта 2. :)
-
Имхо, краткие понятия о каждой из ролей и дисциплин, использующихся в разработке ПО, можно поднять из кучи литературы, да и каждом проекте набор ролей и их важность зависит от кучи факторов. Поэтому голосую за вариант 2: наличие подробного описания конкретики работы аналитика с примерами более насущно :-)
-
Тоже голосую за второй вариант. Методологий разработки много разных, и если выбивать первый вариант, то скорее всего надо привязываться к одной из них, иначе не осилить.
А вот работа с требованиями, особенно их анализ и управление - являются, по крайней мере для меня, более интерсной и насущей темой. Особенно, хотелось бы услвшать (или хотя бы увидеть из презентаций) как управлять изменениями требований без использования специальных программ и возможно ли это вообще. :)
Особенно когда количество системных требований переваливает за тысячу...
-
как управлять изменениями требований без использования специальных программ и возможно ли это вообще. :)
Особенно когда количество системных требований переваливает за тысячу...
:-) Может, конечно, и можно, но у меня первая ассоциация по этой теме "Есть ли жизнь на Марсе, нет ли жизни на Марсе, науке это неизвестно"
-
Интересный подход у народа. Голоса пока разделились поровну 3х3 :)
ИМХО второй подход более теоритизированный, т.е. умения могут быть, но как применять их на практике не совсем понятно. + Не совсем понятно как проводить практические занятии например по разделу Сбору Требований :)
Второй ИМХО более практичный подход. Естественно за основу возьму РУП, но так же буду показывать что и где можно облегчить и выкинуть, а что нельзя.
Понятно, что хорошо бы начать со второго и закончить первым, но сил на это не хватит пока. Так что надо выбрать что-то одно. Голосуем товарищи :)
-
А я бы проголосовала за первый вариант, мне как раз интересны ответы на вопросы типа "Есть ли жизнь на Марсе?". =)) Более конкретные вещи легче найти, прочитать и ассимилировать самостоятельно.
-
Анна, так Вы за первый или второй вариант?
-
Первый. Я просто форму голосования сразу не заметила.
-
Немного поправил описание направлений.
-
Ну раз поправил, то я голосую уже за первый :). Роль аналитика в процессе разработки это уже интересней. Я бы тогда добавил сюда роли аналитика, так как на разных этапах роли могут менятся
-
Поговорили мы с Ирой по аське и пришли к мнению, что нужно сначала выписать цели каждого направления.
Если брать 1ое направление, то цель следующая:
Научить слушателей применять знания Аналитика на практике в процессе разработки ПО
Если брать 2ое направление, то цель:
Научить слушателей правильно работать с Требованиями
Т.е. логичнее идти от 2ого курса, кот. дает как раз знания Аналитика, а потом уже применять их на практике. С другой стороны 1ый курс более приближен к реалям разработки и даст практические советы по работе Аналитика в процессе разработке ПО (что, когда и как нужно делать).
В общем я весь в смятении, что выбрать :)
Ира, кстати, предложила такую идею:
кстати, можно на семинаре 2-3 части делать:
1 - связь с какой-то дисциплиной,
2 - то, чем должен владеть аналитик для этого,
3 - пример
Но тогда получается что в дисциплинах Бизнес Анализа и Анализа Требований нужно говорить о всех знаниях Аналитика :)
-
А что бы не сделать семинар на действительно волнующую многих тему, например, «Как писать ТЗ»? )
-
Ну по идеи такой семинар должен входить и в первое и во второе направление.
-
Тогда уж - как написать "Идеальное ТЗ"? ;)
-
Тогда уж - как написать "Идеальное ТЗ"? ;)
А такое бывает? Идеальное ТЗ для меня это что-то из области сферического коня в вакууме и платоновских эйдосов :-)
-
Управление важнее. И внедряться должно раньше, чем разработка. Не зря же в CMMI жля достижения второго уровня необходимо внедрить управление требованиями, а разработка требований нужна только для третьего.
Проблема только в том, что управление сложнее разработки. Соответственно, исходя из основного принципа преподавания движения от простого к сложному ...
-
Внедрение управления требованиями, как и внедрение любых других технологий выполнения производственных процессов, по идее это задача инженера процессов - технолога, а не аналитика. И пытаться силами аналитика внедрить управление требованиями без поддержки сверху по-моему малоэффективно. Получится опять кусочная автоматизация
-
Внедрение управления требованиями, как и внедрение любых других технологий выполнения производственных процессов, по идее это задача инженера процессов - технолога, а не аналитика. И пытаться силами аналитика внедрить управление требованиями без поддержки сверху по-моему малоэффективно. Получится опять кусочная автоматизация
А в отделе из 3-х-10-ти человек, которых в России большинство, откуда технолога возьмём? Давайте уж определяться с рынком, который вас интересует. Меня — максимально широкий.
-
Управление важнее. И внедряться должно раньше, чем разработка. Не зря же в CMMI жля достижения второго уровня необходимо внедрить управление требованиями, а разработка требований нужна только для третьего.
Проблема только в том, что управление сложнее разработки. Соответственно, исходя из основного принципа преподавания движения от простого к сложному ...
Во-ииии-стину! Но привлекать надо на семинары на языке пользователя (ТЗ, Концепция, Прототип), а там уже продавать ему идею процессов создания (разработки) и управления :) + Ещё коллективной работе научить.
-
А в отделе из 3-х-10-ти человек, которых в России большинство, откуда технолога возьмём? Давайте уж определяться с рынком, который вас интересует. Меня — максимально широкий.
Если иметь в виду роли в процессе, а не должности, то и технолога можно взять. Роль технолога может выполнять и аналитик, просто навыки и знания у этих ролей таки разные. С какой-то точки зрения технолог - бизнес-аналитик, только бизнес-областью для него является разработка ПО.
-
А что бы не сделать семинар на действительно волнующую многих тему, например, «Как писать ТЗ»? )
Тема действительно многих волнует ... будет аншлаг ... но стоит ли его делать for free?
-
Тема действительно многих волнует ... будет аншлаг ... но стоит ли его делать for free?
Поддерживаю. Пора переходить на семинары с упрощенной схемой оплаты.
Вариант:
1. Оплата производится на входе. Сумма достаточно символическая. баксов 10-20.
2. Формируется список.
3. Ответственный человек перечисляет деньги банковским платежом на счет юрлица.
4. Государство заберет себе порядка 40% в виде налогов.
5. Юрлицо заберет некую сумму за выполнение операции.
6. И собственно, лектор получит на руки порядка 40%
В итоге:
* все белые и пушистые перед законом
* отсутствуют высокие накладные расходы по оплате
* с ведущего можно требовать нормально подготовленного семинара - вот за это я готов платить.
-
Поддерживаю. Пора переходить на семинары с упрощенной схемой оплаты.
Вариант:
1. Оплата производится на входе. Сумма достаточно символическая. баксов 10-20.
...
* все белые и пушистые перед законом
Это только если оплата - с кассовым аппаратом.
-
Интересно управление требованиями.
Особенно разработка ИС.
-
Это только если оплата - с кассовым аппаратом.
Естественно. Кассовый аппарат - в банке. Это нормальная практика.
-
дешевле зарегистрировать ПБОЮЛ ... тогда только 13% в виде налогов нужно будет отдать :-).
-
почему 13%? можно и 6% если вид деятельности подойдет для упрощенной системы налогообложения.
-
А НДС?
-
А ЕСН?, А ...
-
На самом деле, вариантов для организационной формы много.
Но их становится особенно много, если нет ясной концепции того, что в эту форму предполагается запихнуть. :)
-
Собственно вопрос не в количестве денег, их как раз много не будет. А в создании прецедента.
-
Собственно вопрос не в количестве денег, их как раз много не будет. А в создании прецедента.
В смысле, главное - в драку ввязаться? :) Тоже метод, и нередко довольно успешный.
-
Вот из-за НДС, часто большим конторам невыгодно связываться с ПБОЮЛ .. эта форма удобна при работе с физлицами в качестве клиентов.
-
Вот кстати интересная статья 10 самых невостребованных профессий на ближайший год (http://livehh.ru/volnovev/entry/10-samykh-nevostrebovannykh-professiy-na)
И самый интересный - это п. 8
-
Вот кстати интересная статья 10 самых невостребованных профессий на ближайший год (http://livehh.ru/volnovev/entry/10-samykh-nevostrebovannykh-professiy-na)
И самый интересный - это п. 8
Вчера как раз на РБК была передача о бизнес-образовании. Полностью не смотрел, но суть уловил так: во время кризиса спрос на образование не уменьшается, а наоборот, возрастает. Но возрастает спрос на качественное образование. Если говорить об MBA, то, скажем так, до десятка самых лучших бизнес-школ не почуствуют оттока, а вот всякие левые, недавно созданные конторы, тихо умрут.
В части системного анализа, имхо, перспективы есть хотя бы потому, что поле здесь ещё нераспаханное. Спрос на хороших специалистов в результате кризиса должен возрасти.
-
В части системного анализа, имхо, перспективы есть хотя бы потому, что поле здесь ещё нераспаханное. Спрос на хороших специалистов в результате кризиса должен возрасти.
Но не раньше, чем кризис закончится, я думаю. В настоящий момент я роста спроса не наблюдаю.
-
Но не раньше, чем кризис закончится, я думаю. В настоящий момент я роста спроса не наблюдаю.
Не раньше, чем люди поймут, что кризис кризисом, а работать тоже надо. Сейчас в основном народ ждёт будущего, а там только хуже будет — когда поймут — вот тогда и пойдёт разговор.
-
кризис кризисом, а работать тоже надо
Хм. Продавать недвижимость тоже вполне себе работа. Тем не менее, пока в риэлторском бизнесе наблюдаются, в основном, одни только сокращения.
Чтобы было что работать, надо чтобы результат этой работы был востребован. На волне замораживания/отказа от многих ИТ-проектов в самых разных организациях, который спровоцирован кризисом, от теоретического понимания людьми (какими, кстати, людьми?) необходимости работы аналитика, самой этой работы существенно не прибавится.
Впрочем, это офтоп. Предлагаю закончить обсуждение кризиса.
-
Потренировать - интересно. :)
Участвовать - уже наверное нет...
Может что-нибудь тогда расскажите на очередном семинаре в Петербурге?