Форум Сообщества Аналитиков

×


Просмотр сообщений

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


Сообщения - Denis Beskov

121
Ещё раз — меня не интересует выбор 1) Word или 2) CASE-средства.

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

122
Почему от этих ошибок должен уберечь опыт технического писательства?
При чём тут техническое писательство?

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

123
Это задачи старшего (ведущего) аналитика, методолога, а вовсе не начинающего.
Это вообще были не задачи, а ситуации, связанные с реализацией рисков. И кто писал про начинающего?

Цитировать
И помочь решать эти вопросы ничего, кроме человека с опытом не поможет. А опыт этот в свою очередь  - кладбище загубленных проектов или наоборот успешных.
Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.

Цитировать
К вопросу - инструментарий или word имеет самое косвенное отношение.
ничего не понял. word – тоже инструмент.

Цитировать
Совершенно непонятно, почему вместо критерия , оценивающего практический опыт аналитика вводится критерий владения/не владения инструментарием.
мне тоже непонятно, о чём вы тут пишете. Кем вводится? Куда вводится? Когда вводится? Где вводится?

Умение выражать знания с чётким выделением действующего лица — важнейший навык аналитика.

124
"Я так вообще не фанат никакого ПО (а скорее открытых систем как класса)"
Денис, а можете поподробнее рассказать, почему?
Потому что в большинстве случаев проблемы в качестве анализа возникают не из-за неприменения инструментов, а из-за невладения техниками работы с требованиями:
1. не учли всех ключевых заинтересованных лиц (как тут поможет ПО?)
2. записали хотелки заказчика как есть, не выяснив реальных проблем (как тут поможет ПО?)
3. не понаблюдали за реальной работой реальных пользователей (как тут поможет ПО?)
4. не обнаружили конфликта невысказанных интересов (как тут поможет ПО?)
5. навязали заказчику свои фичи или технологии (как тут поможет ПО?)

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

125
Появление CAD-систем действительно сопровождалось значительной скоростью перехода на них проектных организаций.
Я вижу причины в том, что 3-хмерные модели физических объектов действительно удобны в работе, т.к. в своих проекциях на экране дают наглядное представление о себе.

С другой стороны, у софта и ИС нет никакой истинной 3D-формы, которая была бы легко постижима человеком. Поэтому модель софта и ИС остаётся ментальной конструкцией, которую каждый участник строит в своей голове по проекциям — будь-то диаграммы процессов, структуры.

Документ (бумажный или электронный) по сути даёт 2,5D-модель, т.к. показывает, в каком порядке эту модель собирать в голове.

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

126
Здравствуйте!

Выпускники нашего онлайн-курса по разработке ТЗ на ПО часто спрашивают о возможности стажировки.

Теперь такая возможность появилась!

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

http://bobrio.com/event/praktikum-upravlenija-trebovanijami/

Практикум проводится полностью дистанционно на русском языке.

Начинается с установочного вебинара 11 апреля, в 19:00 (время московское).

На вебинаре участники:
* сформируют команды (4-5 человек) и выберут лидеров команд,
* выберут тему проектирования;
* запланируют задачи на первую неделю практикума.

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

Практикум заканчивается веб-презентацией, на которой команды представляют и защищают реализованные проекты (20 мая, 19:00).

Программа

1 неделя – установочный вебинар (11 апреля), анализ предметной области, выстраивание рабочего процесса
2 неделя – сбор, анализ и документирование пользовательских требований
3 неделя – разработка функциональных требований
4 неделя – разработка нефункциональных требований
5 неделя – разработка прототипов программного продукта
6 неделя – окончательная проработка всех артефактов бизнес-анализа, вебинар-защита (20 мая)

Преимущества практикума-стажировки

♦ Прикладной. 5% теории, 95% практики! У каждого участника (включая наставников) четко определены роли и задачи,
выполняя которые мы вместе придем к результату. Здесь не будет скучных лекций – только живая работа!
А для теоретической прокачки в вашем распоряжении будет коллекция электронных учебных материалов, доступ к которым вы получите навсегда!

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

♦ Компетентностный. Практикум базируется на профиле компетенций бизнес-аналитика, разработанном с учетом:
требований, предъявляемых, European e-Competence Framework v3.0;
моделей компетенций, разработанной в ходе исследований успешных ИТ-предприятий Беларуси совместно с НТА «Инфопарк».

♦ Дистанционный. Где бы вы ни находились - вы можете принять участие в практикуме
и тем самым получить бесценный опыт работы в географически распределенной команде.

♦ Релевантный. Практикума ведут два опытных наставника, «на совести» которых не только интересные и сложные проекты,
но и выпускники, успешно реализовавшие проекты в таких компаниях, как «Геймстрим», EPAM Systems, Qulix, Oxagile, «Сбербанк-Технологии», А-100 и др.

Регистрация
(чтобы получить скидку 5%, укажите промокод #ssa)

128
О Сайте и Форуме / Алексей Петров и UML2.ru
« : 01 Апреля 2016, 13:45:19 »
В программе AD-2015 вижу, что в ПК и на арене — некий Алексей Петров от UML2.ru: http://it-conf.ru/ru/profile/38994

Каково его отношение к сайту?

В списке участников его не вижу http://www.uml2.ru/category/community/uml2-members/, на форуме тоже его не видно.

129
Цель собственников - извлечение прибыли.
Если бы целью собственников было извлечение прибыли, то они бы вкладывались в торговлю оружием и наркотиками.

130
А что не так с целью компании?:)
Деньги — это условие выживания компании. Цель — это чего хотят добиться собственники, руководители и в идеале — сотрудники. Проследите параллель с целью человека.

131
Целью создания ПО является автоматизация учета приема пациентов.
Опять 25.

Это прям триптих:

1. Цель компании — деньги.
2. Цель ПО — автоматизация.
3. Цель человека — удовлетворение базовых потребностей.

132
А вы видели работающий софт? Я (за приемлемые деньги) - нет. :(
Ну вот например до 10 машин за условную плату — это по-моему приемлемые деньги: https://ruxit.com/startups/

133
Пока непонятно, для чего вообще диаграммы (статические).

134
Вообще есть специализированный софт для автоматизированного сбора информации о конфигурации сети

135
Мы продолжаем серию вебинаров по голосованию участников:
https://www.facebook.com/groups/it.analiz.i.proektirovanie/permalink/971919239559122/

2 апреля, в субботу, с 15 до 16 часов по Москве у нас в гостях Георгий Савельев,
один из соавторов BABOK, рассказчик аналитического марафона.

Георгий расскажет о том, когда и зачем создаются бизнес-требования
и что нужно знать о них и их разработке:

Программа вебинара

1. Когда и зачем нужно документировать бизнес-требования?
2. Когда и как бизнес-требования используются в ходе проекта?
3. Как отличить бизнес-требования от других видов требований?
4. Где и как документируются бизнес-требования в соответствии с международными стандартами?
5. Какую информацию должно содержать описание бизнес-требований и как её получить?
6. Каков оптимальный уровень детализации бизнес-требований?
7. Как отличить хорошие бизнес-требования от плохих?
8. Где и как бизнес-требования отражаются в документах по стандарту ГОСТ 34?
9. Какое место бизнес-требования занимают в Agile-проектах?

Страница вебинара и регистрация: https://sysanschool.timepad.ru/event/312150/