1

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

« : 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

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

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

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

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

2

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

« : 01 Октября 2012, 14:37:25 »

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

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

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

С первым пунктом вроде бы все понятно. Взявшись за задачу, ты должен её оценить и предоставить эту оценку руководителю.
Со второго пункта начинаются вопросы. Если, например, заказчик не ответил мне на письмо и вообще не отзывается, нужно срочно ловить руководителя по скайпу/почте, чтобы он переставил срок. За просроченную задачу будет штраф.

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

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

Объясните мне, пожалуйста, в каких условиях эта система может работать и в чем я, возможно, не права.

P.S. В то же время, если руководитель ставит задачу на исполнителя, он не считает нужным уведомить его об этом дополнительно. Зачем? TFS же присылает уведомления.

3

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

« : 01 Октября 2012, 14:00:03 »

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

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

Я, на вскидку, могу предложить для включения такие пункты:
1. аккуратность оформления;
2. количество опечаток;
3. однозначность терминов, отсутствие синонимов-паразитов;
4. логичность изложения;
5. полнота;
6. соответствие заголовку;
7. достаточно ли примеров и иллюстраций.

У кого-нибудь есть такой опыт сбора обратной связи? Может быть вы уже создавали подобные опросники, поделитесь, пожалуйста.

4

Управление Проектом / Зачем аналитику знать трудоемкость реализации требований?

« : 04 Июля 2012, 17:07:04 »

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

Обсуждаем с тимлидером структурирование и управление требованиями в TFS. Одним из пунктов предложила ему указывать трудоемкость выполнения требований совместно с приоритетом, указанным  Заказчиком. Получила вопрос: "Зачем, как ты будешь это использовать?".

Сходу родились такие варианты ответа:
1. При разговоре с Заказчиком часто возникает вопрос о трудоемкости, в зависимости от этого Заказчик может принять решение о включении этой фичи в текущую или отложить до следующих версий.
2. При указании одновременно приоритета требования и трудоемкости легче строить план работ (на что мне скорее всего аргументированно ответят, что это работа руководителя и я не должна об этом беспокоиться).
3. Слишком большая трудоемкость требования может являться критерием того, что его нужно декомпозировать на несколько. Способ управления качеством моей работы.

Какую еще пользу может принести знание трудоемкости выполнения требования аналитику? И стоит ли настаивать на этом пункте?

5

Резюме / резюме на должность Аналитика

« : 08 Июля 2010, 23:57:54 »

Абрамова Анна Сергеевна

Местоположение: Санкт-Петербург, возможен переезд.

Образование
Высшее, Санкт-Петербургский государственный университет (СПбГУ), факультет Прикладной Математики - Процессов Управления, 2002
Специальность: Прикладная математика, математическое и программное обеспечение вычислительных машин, специалист

Аспирантура по специальности 05.13.18 - Математическое моделирование, численные методы и комплексы программ, специализация: высокопроизводительный и распределенные вычислительные системы, 2005

Опыт работы
1 июня 2008 – настоящее время, ЗАО «Визардсофт.ру»
ведущий системный аналитик/руководитель проекта
Должностные обязанности: моделирование и построение бизнес-процессов, выбор и внедрение программного обеспечения, анализ перспективных разработок, написание технических заданий, контроль текущих работ, подбор персонала.
Основные проекты: организация работы отдела продаж, веб-портал linuxwizard.ru, автоматизация работы технической поддержки.

19 мая 2008 – 30 июня 2008, ЗАО «Визардсофт»
Системный аналитик
Должностные обязанности: Создание шаблонов документации, проведение интервью с пользователями, написание технических заданий, тестирование программных продуктов, написание эксплуатационной документации.
Основные проекты: АРМ сотрудников технической поддержки компании, система учета рабочего времени для руководителей отделов.

С сентября 2003 – декабрь 2009, СПбГУ ПМ-ПУ
Ассистент (Частичная занятость)
Должностные обязанности: Чтение лекций и ведение практических занятий по курсам «Технология программирования» (I-II курс), «Основы Web-программирования» (III курс), «Технологии сети Интернет» (III курс).

С мая 2006 – февраль 2008,
СПбГУ ИТМО, научно-исследовательская лаборатория «Параллельное математическое обеспечение»
Младший научный сотрудник (Полная занятость)
Должностные обязанности: создание учебных пособий, научно-исследовательская работа, преподавательская деятельность, проведение патентных исследований.
Основные проекты: разработка учебно-методического комплекса "Высокопроизводительные вычисления",  проекты по созданию программного обеспечение для моделирования высокопроизводительных систем для Грид и кластерных вычислительных систем,  создание мобильной платежной системы (совместно с ОАО «Алкор Пэйкэш»).

Март 2003 – Март 2006, внештатный сотрудник (фриланс)
веб-разработчик
Должностные обязанности: полное создание сайта от проектирования до внесения содержимого и поддержки.
Основные проекты: создание сайтов компании «Арсенал-Моторс», группы строительных компаний «Петростиль», «Радио44».

Иностранные языки и компьютерные навыки
Английский – лучше «чтение технической литературы», но ниже уровня «разговорный» по причине отсутствия практики,
финский – базовый.
Работа с ОС Windows 95/98/2000/XP на уровне администратора, UNIX-подобными - на уровне пользователя.
Технологии, языки: SQL, C++, PHP, JavaScript, HTML/СSS;
Технологий параллельных вычислений OpenMP, MPI.
Инструментальные средства: MySQL, MS Visual Studio, Intel Threading Tools, PhotoShop, MS Visio, CMS Joomla.

Повышение квалификации
Октябрь 2008 — ноябрь 2009, Семинары сообщества системных аналитиков: «Планирование требований», «Классификация требований», «Техники вариантов использования»
Февраль 2006, Зимняя школа-практикум молодых ученых и специалистов «Технологии параллельного программирования»,  Intel, Нижегородский государственный университет, г. Нижний Новгород
Февраль - май 2004 года,  Методы высокопроизводительных вычислений,  Центр переподготовки и повышения квалификации научно-педагогических кадров по естественнонаучным направлениям (ЦППК ЕН)

Профессиональные интересы: системный анализ, построение web-сервисов, web-дизайн, высокопроизводительные вычисления, преподавательская деятельность.

Пожелания к месту работы:

• возможность развиваться в качестве аналитика,
• в области web-сервисов,
• и/или высокопроизводительных вычислений,
• не испугает возможность обучения новой предметной области.

Вакансии с другими параметрами также рассматриваются =)

6

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

« : 31 Июля 2009, 16:40:25 »

Сегодня празднуется День Системного Администратора. Всех имеющих отношение к этому празднику Поздравляю!

По этому поводу возникла мысль: а почему мы не празднуем День Системного Аналитика. Кто-нибудь слышал о такой дате? Если нет -- предлагаю выбрать и праздновать!

7

Бизнес-анализ и Целеполагание / Анализ рабочих процессов в начале деятельности компании

« : 16 Марта 2009, 14:55:21 »

Дорогие коллеги!
Я обращаюсь к вам за помощью, так как поняла, что самостоятельно с областью, с которой мне пришлось столкнуться, в обозримые сроки не справлюсь.

Контекст: организуется небольшая компания (точнее направление деятельности более крупной компании, состоящее пока из пяти человек), которая предлагает настройку ИС на основе Linux для небольших фирм. Для эффективной работы с клиентами решено построить информационный сайт с доступом к двум веб-сервисам, которые должны помочь работать клиенту и специалистам компании (задача сервисов, грубо говоря, техподдержка).

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

Я — зеленый, но смело-инициативный (а главное — единственный в этом проекте) системный аналитик, который пытается охватить эту ситуацию целиком. Я вижу, что информации для полноценной работы над проектом не хватает, причем сами руководители не могут её предоставить, потому что они об этом «еще не думали».

Необходимо: построить сайт, сервисы и ПО для внутренней работы сотрудников компании. Больше всего меня сейчас беспокоит последнее. Основной задачей внутреннего ПО, за проектирование которого я отвечаю, является сбор информации в процессе работы и с клиентами и для менеджера клиентов и для техподдержки — такая разновидность CRM. Информация попадает в систему из веб-сервисов, вносится менеджерами клиентов и специалистами, выполняющими заказ. Соответственно, каждый из них должен иметь доступ к той части информации, которая ему нужна для работы.

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

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

С моей стороны уже поступило руководству несмелое предложение привлечь какого-нибудь опытного консультанта от интегратора, который уже собаку съел на внедрении CRM и/или КИС. По крайней мере это точно быстрее, чем писать свой софт. Пока отклика предложение не получило.

При попытке найти что-нибудь про описание бизнес-процессов пока наткнулась на одну вещь, которая меня заинтересовала: цепочка создания дополнительной потребительской стоимости М. Портера. Из той-же статьи поняла, что предельно общие процессы, описанные в данной модели нужно подогнать под частный случай «сборка под заказ», т.к. примерно так можно охарактеризовать  предоставляемые услуги.

Вопрос: в правильном ли направлении я пошла? Куда и как мне дальше двигаться? Не усложняю ли я слишком ситуацию (бывает за мной такой грех =))?

Очень жду уточняющих вопросов и предложений.
Заранее спасибо.