16

Конференции Семинары и Тренинги / Re: ЛАФ-2013. Организация

« : 27 Января 2013, 13:35:16 »

А по датам планируем так же? Конец июня, начало июля?

17

Конференции Семинары и Тренинги / Re: ЛАФ-2013. Организация

« : 27 Января 2013, 13:34:06 »

Согласна  с Денисом. Нужно задать определенную тематику. Это сделает ЛАФ более полезным. Разброс тем это не сильно ограничит, а вот подумать о том, как интересующая тема связана с тематикой заставит. ЛАФ будет более осознанным.

18

Системный Анализ и Требования / Re: структура документа для описания бизнес-правил и их реализации в системе

« : 04 Декабря 2012, 22:06:16 »

Что такое «недостаточно просто интуитивно»?

Например, пользователи документа в упор не видят ссылку на развернутое описание логического условия. Аналитик со стороны заказчика говорил мне, что надо развернуть описание логического условия. Пришлось явно обратить внимание, что есть ссылка и соответствующий пункт, в котором все расписано. Разработчик также задавал вопрос "А как это проверить?", опять же пришлось отдельно обращать его внимание, что описание есть в документе.

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

Расскажи, пожалуйста, что ты имеешь в виду под реестром? Очень интересно!

19

Системный Анализ и Требования / структура документа для описания бизнес-правил и их реализации в системе

« : 04 Декабря 2012, 14:34:37 »

Коллеги, добрый день!

В рамках системы, над которой я сейчас работаю, реализуется большое количество сложных бизнес-правил. Каждое бизнес-правило содержит порядка 10 бизнес-условий.  Для проверки этих условий необходима информация из нескольких внешних систем заказчика. Исторически сложилось, что информацию о бизнес-правиле и технических подробностях его реализации заказчик присылает в одном документе в смешанном виде, причем часто с упором в реализацию: "Параметр X должен иметь значение в диапазоне от N до M (значение параметра смотреть в поле Y таблицы Z системы W)". Структуру всех систем заказчика наша команда знает еще недостаточно хорошо, чтобы не нуждаться в таких пояснениях от заказчика, но и такая структура документа нечитабельна и нежизнеспособна.

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

Что сейчас стараюсь делать для каждого бизнес-условия:
1. Узнать, что означает параметр X в физическом мире, почему для него такие ограничения. Сформулировать условие с точки зрения бизнеса.
2. Доформулировать логические условия проверки бизнес-условия, если необходимо.
3. Указать источники данных, необходимые для проверки логических условий.

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

Вопрос: как эту информацию лучше организовать в качестве документа с приложениями, чтобы в основном документе была вся информация, которая необходима для понимания задачи разработчиками и понимания реализации пользователями; стоит ли всю техническую информацию выносить в приложения?

У меня на данный момент используется такая структура:

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

бизнес-условие 1	Логическое условие 1  Логическое условие 2 (подробное описание см. в п.п. 3.2.2)
бизнес-условие 2	Логическое условие 3
3.2.2 Логическое условие 2

Необходимые источники данных (внешние системы, таблицы, поля в них) указываются в отдельном Приложении.

Проблемы текущего решения:

• опыт показал, что такая структура недостаточно просто интуитивно считывается пользователями документа;
  
• все еще непонятно куда и под каким соусом включать необходимые технические подробности работы с внешними системами.

Буду благодарна за комментарии и предложения.

20

Конференции Семинары и Тренинги / Re: МСК, 24 ноября, суббота, Введение в профессию системного аналитика

« : 19 Ноября 2012, 15:44:53 »

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

21

Для всех / Re: обратная связь по документации с помощью опросника

« : 07 Ноября 2012, 22:28:51 »

Такая интересная дискуссия получилась. И очень актуальная. =)

22

Обсуждение статей / Re: Req Labs 2012, Киев, 9-10 ноября

« : 02 Ноября 2012, 19:34:04 »

Рекомендую по жилью airbnb.com

Денис, спасибо. Это мысль!

23

Обсуждение статей / Re: Req Labs 2012, Киев, 9-10 ноября

« : 02 Ноября 2012, 16:35:53 »

Решила ехать через Москву. Кто едет из Москвы, ответьте, каким поездом едете?

Кстати, может и порекомендуете что-нибудь с жильем?

24

Для всех / Re: обратная связь по документации с помощью опросника

« : 02 Ноября 2012, 14:23:59 »

Если обратная связь слабая - значит, все хорошо.

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

Я тоже так думала, пока не увидела релиз.

25

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Ноября 2012, 20:50:57 »

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

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

26

Обсуждение статей / Re: Req Labs 2012, Киев, 9-10 ноября

« : 31 Октября 2012, 16:42:23 »

Вот я тоже думаю съездить.

27

Сообщество Аналитиков / Re: День Системного Аналитика

« : 12 Октября 2012, 13:34:18 »

Буду в Москве 20-22 октября. Организуете встречу?

28

Управление Проектом / Re: один способ управления задачами в команде

« : 02 Октября 2012, 12:13:16 »

А есть возможность внести изменения в схему?

Если, например, привязать срок не к закрытию заявки, а к ее выполнению?
Как допустим в Jira, выполнил задачу в срок, и перевел ее обратно на руководителя. А он ее пусть хоть до второго пришествия проверяет, ты уже все сделала и со всех сторон молодец.
Тогда появится возможность и руководителей штрафовать:)

 Костя, она была такая до этого.

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

29

Для всех / Re: обратная связь по документации с помощью опросника

« : 02 Октября 2012, 11:28:45 »

Коллеги, большое спасибо за ответы!

Вы правы.

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

По качеству документа лучше разговаривать с конкретным пользователем.

30

Для всех / Re: обратная связь по документации с помощью опросника

« : 01 Октября 2012, 17:07:15 »

Согласна, надо знать цель. Для прогеров, я качество своей доки оцениваю просто, если ко мне прогер не обращался с вопросами, то класс. А если задавал вопросы по какой нибудь шняге, то я фиксирую себе в голове и дописываю в следеющем.
Для простых пользователей, важно картинки. Читать они не любят. А для "подшивки" - главное красиво, можно и не содержательно, все равно читать никто не будет.
 

А вот для меня, если прогер не обращался с вопросами - это очень плохо. Либо не читал, либо прочитал и ничего не понял. В любом случае сделал по своему, потом придется переделывать. Может в сработавшихся командах на длительных проектах это правило не работает, но я таких не видела.