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

×


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

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


Сообщения - anton morozov

Страницы: 1 2 3 4 »
1
Для всех / Re: Практика для БА, вопрос
« : 24 Января 2017, 16:42:30 »
Не хотите axure освоить? Потом можно будет на поприще прототипирования подрабатывать даже и на фрилансе. Это хоть какая-то проектная практика. И от скуки поможет и навык для БА  полезный. Я догадываюсь, что это  Вам не совсем интересно, но вдруг ... 

2
Sparx / Re: Нужны примеры описания API в UML
« : 26 Декабря 2016, 19:12:00 »
Стоит ли вообще делать описание API в UML?

3
Вопрос 1. Приведите, пожалуйста, примеры сред, в которых используется ПО (имеются ввиду конечные пользователи или что-то другое)?

Примеры сред, в которых используется ПО:


- Отдел X1 в центральном отделении компании А
- Отдел X2 в областном отделении компании А
- Отдел Y в компании B


- Отдел F1 c одним сотрудником в компании L
- Отдел F2 c 2 и более сотрудниками в компании L1


- Команда разработки 1 проекта C
- Команда разработки 2 проекта C


- Выборка пользователей целевой аудитории ЦА1
- Выборка пользователей целевой аудитории ЦА2


- Отрасль индустрии А
- Отрасль индустрии Б

- Специалист А в области Y
- Специалист Б в области Y


Сред великое множество и каждая из них по своему уникальна. Понятно, что есть и типовые моменты(особенно, если работаешь в интеграторе, специализирующимся на ...), но с этим надо быть осторожным. “Типовые моменты” могут сыграть с аналитиком злую шутку. Добавлю, что “каждое поле битвы - это новое поле битвы”. Эту мысль находил у Суворова и Сунь-цзы. Они хорошо знали цену ошибок при оценке обстановки.

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

Среда - это совокупность агентов, их взаимоотношений и правил, определяющих эти взаимоотношения, в контексте определенной деятельности. (отсебятина)

В определенном ключе тему раскрывает  Dave Snowden и его Cynefin framework, особенно если послушать его выступления в оригинале.

4
2  a.skulskiy
Посмотрите вот это видео с 13 й минуты -> https://vimeo.com/183546463
Там у них тоже протоипирование значится как  одна из основных обязанностей аналитика ...

PS
    Видео замечательное.

5
Бутстрап выбран по той причине, что в нем очень много элементов с нормальной стилистикой.
+ Его используют разработчики, поэтому мышление аналитика в нативных элементах бутстрапа частично упрощает всем жизнь.
+ Он нормально развивается и поддерживается.
Не обязательно брать бутстрап за основу библиотеки, он с ним проще, чем без него.

6
Ну я отвечу так:

1. Не во всех командах есть отдельные ux проектировщики, но проектировать пользовательское взаимодействие нужно всегда, когда оно есть.
 
2. Сокращать expectation gap нужно на любом проекте при любом составе команды. Прототипы как инструмент тут заходят очень хорошо.

3. На западе прототирование считают одной из requirement elicitation techniques.
Владение requirement elicitation techniques является прямой обязанностью аналитика …
 
4. Стараюсь делать проекты на совесть, поэтому если вижу что наметилась дыра с проектированием взаимодействия, то я закрываю её специалистом с наибольшей компетенцией в этом вопросе. Если это приходится на мою долю, то я делаю всё от меня зависящее. Если нужно освоить axure, то я это делаю. Если нужно ускорить работу в axure, то я делаю библиотеки. Если нужно читать книжки по проектированию взаимодействия, то я это делаю. Ну и дальше ...

5. Прошу меня понять. Я для себя всё уже давно решил с протипированием. Сейчас меня инетерсует взаимодействие с коллегами, которые реально хотят улучшить практику использования axure. Я готов отвечать на конкретные вопросы по axure, готов исследовать или делиться опытом. Готов пошарить и совместно развивать ту же библиотеку ...  Но я не хочу разводить дебаты на тему “зачем аналитикам axure” или “почему именно axure”!

7
2 anton morozov
Антон, непонятно для каких целей и как используется Axure в работе аналитика.
Если не трудно расскажите пожалуйста.

Трудно. Это очень обширная тема для раскрытия новичкам. Требует большой вводной части как по анализу, так и по процессу разработки. Для поверхностного раскрытия требуется лекций часа на 3 – 4. 
Это явно выходит за рамки темы «Использование библиотек Axure». Кроме того, вся интересующая информация есть в открытом доступе.



8
Купил на ЛитРесе. Прочитал. У меня всё заканчивается на главе «IX. Пользовательский интерфейс». Так и должно быть?

9
Цитировать
Исследования нет. Это моё мнение, что людей, которые называют себя ИТ-аналитиком в 21-м веке и не умеют читать по-английски, быть не должно.

+

10
Обучение / Рассказ о СА/БА в школе.
« : 30 Августа 2016, 12:58:53 »
Коллеги!

У меня появилась возможность в школе рассказать старшеклассникам про профессию СА/БА. Пока тема и формат точно не определены. Возможно, это будет что-нибудь общее по разработке. Возможно, это будет в форме игры. Многое будет зависеть от кругозора школьников в плане проектной деятельности. Интерес со стороны школы – расширения кругозора о возможных профессиях. Интерес с моей стороны – популяризация деятельности СА/БА.
Времени на подготовку достаточно, чтобы сделать «Круто». И я буду прилагать максимум своих усилий. Если у кого-нибудь есть опыт на эту тему, то прошу поделиться.

11
Добрый день, коллеги.

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

Для острастки приведу некоторые примеры из библиотеки. -> см. вложение

Как вы понимаете, я создал эту тему, чтобы обсудить опыт использование библиотек Axure.
Если быть более точным, то меня интересует:

1.Ощущаете ли вы  ускорение работы при использовании библиотек?
2.Какие библиотек наиболее полезны ? Отдельные списки/кнопки/иконки/прочие мелкие элементы или заготовки полноценных экранов ?   
3.Какую версию axure используете ?
4.Чего не хватает в библиотеках, которые вы используете?
5.Чего не хватает в самой axure ?

PS

     Раз уж я задаю вам вопросы, то буду готов ответить на ваши по axure.

12
Кстати, о практике. У меня на глазах из-за непонимания этой разницы на два дня уронили серьезную федеральную систему. Потом ручками подняли, и пару месяцев командой переделывали за свой счет. "Классическая" это проблема или нет, утверждать не возьмусь. Но однозначно проблема.

Ни как не могу себе представить, как должен  должен выглядеть весь процесс разработки, чтоб «незнание разницы между классификатором и справочником» приводило к падению системы на 2 для + реворк на 2 месяца …  Я не пытаюсь подвергнуть сомнению Ваши слова, но просто пытаюсь представить.

13
Кстати, о практике. У меня на глазах из-за непонимания этой разницы на два дня уронили серьезную федеральную систему. Потом ручками подняли, и пару месяцев командой переделывали за свой счет. "Классическая" это проблема или нет, утверждать не возьмусь. Но однозначно проблема.

Не "Платон" часом ?

14
А искать проще там, где светло. То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора

Я не хочу вступать в защиту аналитиков, которые не знают разницы между справочником и классификатором.  Но я хочу сказать, что это не то,  что приводит к наиболее серьезным и классическим проблемам на проекте.
А вот неумение нормально работать на этапе выявления зл / требований (elicitation по Вигерсу) приводит действительно к серьезным долгоиграющим проблемам на проекте или в продукте. Кажется, что аналитиков с высоким скилом выявления мне встречалось гораздо меньше тех, которые знают «разницу между справочником и классификатором».

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

2 Humbert
Этап выявления в проекте идет всегда вообще самым первым и базируется на большим количестве методик. Именно методики, а не инструменты рулят на этом этапе. 

PS
Предположу (опираясь на то, что я видел и знаю об аналитике в заказной разработке в РФ), что основная проблема у нас в проявлении нигилизма к «выявлению».
С одной стороны, никто не хочет инвестировать в «выявление».
С другой, когда проект завален или «условно успешен», все проблемы объясняются «неадекватным заказчиком», «недостаточным бюджетом», «слабым менеджментом»,  но никто никогда не говорит что «мы мало времени уделили выявлению требований или у нас были проблемы в методиках выявления».


15
Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559

Испытывал очень сильные душевные волнения во время просмотра. Три года назад пытался реализовать схожие подходы на ЕА. Тогда не хватило опыта, сил, ума и я думал, что это всё плод моих перфекционистских фантазий и на практике мало осуществимо, дорого и никому не нужно. Эти видео подтверждают, что я шел в правильном направлении. Спасибо команде касперского. Это очень ценно!

Страницы: 1 2 3 4 »