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

×


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

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


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

586
ПО Аналитика / Re: Axure практика
« : 09 Сентября 2013, 18:17:02 »
Для HTML-JS-сайтов думаю это вполне реализуемо.

Можно было бы выбрать шаблонный/JS фреймворк (twitter bootstrap?) и вперёд.

587
Ещё есть пара мест на тренинг.

588
ПО Аналитика / Re: Axure практика
« : 09 Сентября 2013, 17:58:55 »
Как сделать так, чтобы генерируемый им код был промышленным, а не прототипным? :)

589
Первый тренинг в осеннем сезоне пройдёт в воскресенье, 22 сентября.

590
ИМХО Шаблоны Документов нужно взять у Вигерса. Они прикреплены к этому сообщению.
Саша, поскольку Вигерс (снова?) начал продавать эти шаблоны, а деньги направляет на поддержку парализованного консультанта, то я думаю, что продолжать распространять эти шаблоны бесплатно не очень этично.

Можно поставить ссылку на http://processimpact.com/goodies.shtml, 150 рублей заплатить для тех, кому надо, не проблема

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

15 сентября дизайн-студия Мотка и Школа системного анализа и управления
проводят тренинг «Проектирование пользовательских интерфейсов».

Ведёт тренинг Фил Смирнов, арт-директор и владелец студии.

Тренинг ориентирован на всех участников процесса проектирования интерфейса —
заказчиков, менеджеров продуктов, менеджеров проектов, аналитиков,
проектировщиков, разработчиков и прочих специалистов.

Участники смогут познакомиться с высокоэффективным процессом,
построенном на современных методиках проектирования —
техниках работы с запросами клиента (Design Thinking),
превращения пользователя в клиента (Customer Journey),
пользовательских сценариях (Usage Scenarios) и
техниках описания пользователей (Personas).

Программа тренинга и регистрация:
http://school.system-analysis.ru/trainings/user-interface-design/

592
о, пошла психодиагностика по интернету

593
Серия вебинаров «Разработка новых профессиональных стандартов в области информационных технологий»

Под эгидой ассоциации АП КИТ ведется разработка новых профессиональных стандартов в области ИТ в рамках федеральной программы, инициированной Указом Президента РФ №597 от 7 мая 2012 г.

На этой неделе пройдут вебинары по представлению проектов новых профессиональных стандартов в области ИТ.

Я представлю проекты стандартов «Системный аналитик» и «Менеджер ИТ-продуктов».

Приглашаем специалистов в соответствующих видах проф. деятельности, специалистов в области управления персоналом и других заинтересованных лиц.

Регистрация: https://www4.gotomeeting.com/register/249322815 (единая для всех вебинаров)

График вебинаров (указаны названия проф. стандартов):

11 сентября (среда)
11:00-11:50 «Программист»
12:00-12:50 «Руководитель разработки программного обеспечения»
13:00-13:50 «Администратор баз данных»
14:00-14:50 «Специалист по тестированию в области ИТ»

12 сентября (четверг)
11:00-11:50 «Архитектор программного обеспечения»
12:00-12:50 «Системный аналитик»
13:00-13:50 «Специалист по информационным системам»
14:00-14:50 «Руководитель проектов в области ИТ»

13 сентября (пятница)
11:00-11:50 «Менеджер продуктов в области ИТ»
12:00-12:50 «Менеджер информационных технологий»
13:00-13:50 «Специалист по информационным ресурсам»
14:00-14:50 «Технический писатель (Специалист по технической документации в области ИТ)»


594
Существуют ситуации, в которых этому аналитику необходимо принять для себя решение, на чьей он стороне. На стороне пользователей продукта или его разработчиков?
На стороне заказчика.

Цитировать
Чьи финансовые интересы отстаивать: фирмы исполнителя или фирмы заказчика?
Работодателя.

Цитировать
Считаете ли вы, что «клиент всегда прав»?
Нет.

Цитировать
Можете ли вы «уволить» клиента?
Когда я выступаю как фрилансер — да. В других случаях обычно нет.

Цитировать
Считаете ли вы верной позицию «Аналитик должен лишь фиксировать требования. Судить об их реализуемости должен архитектор, а управлять скоупом руководитель проекта»?
Я не считаю верной позицию, что аналитик должен лишь фиксировать требования. Он должен их разрабатывать. Фиксирует пусть секретарь.

Судить о реализуемости имеет право кто угодно, включая клиента, пользователей и бабушку клиента.

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

От аналитика могут ожидать, что он будет называть оценки.

Однако как только он это сделает, от возьмёт на себя ответственность, а цепочка ответственности удлинится и, таким образом, ухудшит ситуацию.

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

Это в случае, если у вас нет самоуправляемой команды — если была бы, полезно, чтобы она сама называла сроки клиенту.

Управлять рамками проекта конечно должен РП.

595
Цели компонента прописаны в задании (там компонент-то всего лишь предполагает возможность ведения блога зарегестрированным пользователям). Насчет критериев задумаюсь, спасибо!

Ведение блога больше похоже на задачу, чем на цель.

Цель — это то, что стоит в конце фразы
«Я, как зарегистрированный пользователь сайта, хочу вести блог, для того, чтобы … ».

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

596
Я не сталкивался.

Рекомендую креатив начать с выработки вменяемых целей компонента и критериев его успеха.

597
7-го сентября, в субботу, с 12 до 14,
я проведу вебинар «Требования к массовым продуктам».

Те, кто впервые сталкиваются с продуктовой разработкой, внезапно обнаруживают,
что старые, классические методы разработки требований по Вигерсу/Леффингуэллу/Коберну/Кону не то чтобы работают:
* Заказчика в явном виде нет,
* Пользователей либо нет либо сразу тысячи и контакта с ними нет,
* Бизнес-процессы у всех потенциальных клиентов разные,
* В команде сотни идей о том, что можно сделать в продукте, но непонятно, с чего начать и почему.

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

Чем продуктовый мир отличается от тесного, но уютного мира внутренней разработки
или от менее уютного, но всё-таки с понятными правилами мира разработки заказной?

О чём стоит знать, начиная делать новый продукт?

Каких типичных ошибок можно избежать?

Об этом я расскажу на вебинаре и отвечу на ваши вопросы.

Программа вебинара и регистрация:
http://school.system-analysis.ru/mass-product-reqs/

598
Кстати, структура документа требований заинтересованных лиц по
ISO/IEC/IEEE 29148:2011 Системная и программная инженерия. Процессы жизненного цикла. Разработка требований

1. Introduction
1.1 Business purpose
1.2 Business scope
1.3 Business overview
1.4 Definitions
1.5 Stakeholders

2. References

3. Business management requirements
3.1 Business environment
3.2 Goal and objective
3.3 Business model
3.4 Information environment

4. Business operational requirements
4.1 Business processes
4.2 Business operational policies and rules
4.3 Business operational constraints
4.4 Business operational modes
4.5 Business operational quality
4.6 Business structure

5. User requirements

6. Concept of proposed system
6.1 Operational concept
6.2 Operational scenario

7 Project Constraints

8. Appendix
8.1 Acronyms and abbreviations

599
Не очень понятно, что включает в себя п. 1 Контекст и ЗЛ
Контекст — это что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать. ЗЛ — заинтересованные лица.
Цитировать
Бизнес-процессы вы описываете в общем виде или на данном этапе также прорабатываете отдельные действия пользователей в системе?
В общем виде почти всегда. Если системы ещё нет, то конечно не описываем отдельные действия, т.к. это уже проектирование.

Цитировать
т.е. есть ли необходимость на данном этапе сбора требований отдельные сценарии бизнес ВИ прорабатывать?
Зависит от проекта. В общем случае это делать полезно.

Цитировать
и какие еще диаграммы вы включаете в раздел Концептуальная модель предметной области?
Понятия и связи, Состояния.

600
Я включаю в БТ:

1. Контекст и ЗЛ
2. Цели создания системы и критерии достижения
3. Ключевые требования к решению и их приоритеты
4. Ограничения на решение

Приложения:
А. Описание бизнес-процессов
Б. Бизнес-правила
В. Концептуальная модель предметной области

Цели, сформулированные в виде результатов — это, в каком-то смысле и есть «что должно быть сделано системой», если под системой понимать ИС, включающую людей :)

«Бизнес ВИ» — это разновидность формата описания бизнес-процессов на уровне бизнес-фунций и операций.

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