61

Вакансии / Re: Срочно!!! Требуется бизнес аналитик

« : 12 Апреля 2016, 13:37:53 »

(вспоминается анекдот про молодого рекрутера, старого рекрутера и большую стопку резюме)

Только вот стопка отсутствует.

62

Вакансии / Re: Срочно!!! Требуется бизнес аналитик

« : 11 Апреля 2016, 18:40:56 »

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

Как это соотносится с утверждением:

Это значит, что я ищу свободного бизнес - аналитика, который сразу готов приступить к работе!

63

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 17:20:52 »

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

+1

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

Бумажный документ не требует никаких технических средств для применения по назначению, ему безразличны форматы хранения данных, совместимость версий ПО для просмотра (и стоимость их приобретения), долговечность носителя и т.д., и т.п. Он "всегда готов".

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

+1

Я полагаю, что у формального документа требований основное предназначение это "поиск ошибок на ранней стадии" и "управление проектом". Для управления удобней представление в трекере (любом), для поиска ошибок... Кому как, но для меня бумажный вариант наиболее предпочтителен.

64

Примеры / Re: ПО для учета посещений пациентами приема

« : 05 Апреля 2016, 12:59:25 »

Орлов, "Записки автоматизатора"

Развлеканец. Ключевая фраза, по которой можно отличить этот тип хозяина: «Из-за этого я теряю пять тысяч долларов каждые пятнадцать минут». Время и сумма могут варьироваться – неизменно одно: если вы начнете приставать к такому с просьбой привести расчеты, на которых строится это утверждение (чего я делать очень не рекомендую), то расчетов не дождетесь, но через некоторое время приведете развлеканца в бешенство с тяжелыми последствиями для себя. Традиционное поведение бизнесмена у представителей этого типа претерпело одно маленькое изменение: вместо установок «Заработать кучу денег и развлечься на них» или хотя бы «Развлечься зарабатыванием кучи денег» работает установка «Развлечься своим бизнесом».

65

Примеры / Re: ПО для учета посещений пациентами приема

« : 01 Апреля 2016, 16:26:45 »

Оставлю пока в стороне "Цели", "Назначение" и т.д. Просто исходя из правил ведения реестра, один вопрос - один тикет.

1.   Название
«Запись существующего в системе пациента на новый прием»
2.   Итерация
3.   Описание
Врач хочет записать существующего пациента на прием
4.   Предусловия
Врач выполнил вход в систему. Врач находится в главном окне системы
5.   Триггер
Врач вызывает функцию записи существующего пациента на прием
6.   Основной поток действий
1.   Система показывает форму записи пациента на прием
2.   Пользователь выбирает пациента и заполняет дату и время будущего приема
3.   Система проверят введенные данные и подтверждает их правильность
7.   Альтернативные потоки действий
2.1. Пользователь отказался от выбора пациента или не указал дату и время приема:
2.1.1. Система уведомляет пользователя о необходимости ввода данных
2.1.2. Возврат к шагу 1. Основного потока
3.1. Система обнаруживает неверно введенную дату или время:
3.1.1. Система уведомляет пользователя об ошибке ввода
3.1.2. Возврат к шагу 1 основного потока
8.   Постусловия
В системе появляется запись о новом приеме
9.   Бизнес правила
10.   Замечания
11.   Автор и дата

Выше приведен пример одного из сценариев...
Покритикуйте его, пожалуйста...
Есть еще вот такие вопросы:
Нужно ли описывать действия пользователя на сообщение об ошибке: к примеру если он ответил да или нет... Если да - то закрыть текущее окно и обновить форму, если нет - оставить заполненную форму на экране

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

66

Для всех / Re: Помогите пожалуйста с тестом «Методология разработки ПО»

« : 29 Марта 2016, 12:08:20 »

Это бразильская система образования. Описана в главе "O Americano, outra vez!" книги "Вы, конечно, шутите, мистер Фейнман!" http://lib.ru/ANEKDOTY/FEINMAN/feinman.txt

Кстати. Книгу настоятельно рекомендую. И отдельно эту главу. После нее многое проясняется.

67

Примеры / Re: Сценарий использования выдачи книги

« : 29 Марта 2016, 11:59:55 »

Популярные грабли. Все хорошо будет до тех пор, пока этот срок не начнут менять.

Угу. Плюс для разных книг срок разный (в зависимости от популярности).

68

Для всех / Re: Разработки

« : 24 Марта 2016, 15:33:45 »

Это адаптация PMBOOK для российского рынка. Требований по применению нет - речь идет о том, что его разрабатывали вроде с этой целью

PMBoK... Как бы это помягче... Ну, не стоит  на него ориентироваться. И читать тоже.

69

Бизнес-анализ и Целеполагание / Re: Вопросы о бизнес-целях. Как правильно задавать и бороться с сопротивлением

« : 24 Марта 2016, 12:38:09 »

Присоеденюсь к mironov.work. С удовольствием бы ознакомился бы с какой-нить литературой по этому поводу. Сейчас работаю с коллегами , которые уверенно различают между собой задачи, функции, цели... Но при этом мне их обьяснения кажутся несколько схоластическими. В процессном подходе все несколько проще - есть цель процесса, есть выходы процесса. При этом и то и другое определяется в реальности и легко проверяется на интерпретабельность. 

Как правило, формулирование цели является наиболее сложным из всех видов работ по созданию ТЗ (34.602). Кроме того может иметь место прямой запрет заказчика на указание цели. В этом случае стоит поместить в этом разделе обтекаемые и ничего не значащие фразы, изложенные канцелярским языком. Предельно непонятные.

На почитать.
Из очень простого: Голдратт Элиягу, "Синдром стога сена"
Далее, его же "Цель-1"
Как ни странно, ГОСТ 24.104-85. Да, да от 1985 года.
--------------------
В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
ГОСТ 24.104-85: Ввод в действие АСУ должен приводить к полезным технико-экономическим, социальным или другим результатам, например:
-    снижению численности управленческого персонала;
-    повышению качества функционирования объекта управления;
-    повышению качества управления и др.
Отраслевая АСУ должна обеспечивать:
-    улучшение характеристик объекта управления (повышение производительности труда в отрасли, повышение качества продукции, своевременное выполнение поставок продукции, снижение себестоимости выпускаемой продукции);
-    совершенствование процессов обработки информации (снижение стоимости обработки информации, повышение достоверности исходных данных, повышение точности и оперативности расчетов);
-    совершенствование организации выполнения функций управления (в частности, рациональное распределение работ между подразделениями аппарата управления, вычислительными центрами и научно-исследовательскими организациями и предприятиями).


-------------------
В 1985 госзаказчики и разработчики были гораздо более адекватны.

70

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 03 Марта 2016, 13:12:42 »

Полагаю обсуждение содержательной части более - менее закончено. Можно перейти к оформительской части.

-- Построение ------------------------------------------
Как и Леонид я часто строю такие схемы в голове.
При повышенной сложности - стикеры или тетрадь в клетку А4.
Изредка доску или флипчарт.

-- Фиксация ------------------------------------------
Но в какой то момент нужна фиксация результата. Почерк у меня "не очень", и сканирование не очень помогает. Почти всегда под рукой есть пауерпоинт. В нем чаще всего я фиксирую простые диаграммы. При необходимости и IDEF, и стейт, и прочие. Так быстрее, проще и эффективнее. Иногда использую визио. Приведенная в статье диаграмма быстрее всего строится во флаинглоджик. Набор выразительных средств там достаточно куцый и на освоение уходят минуты. Минимум возможностей - очень высокая скорость фиксации готового результата. Заметим, фиксации готового результата с наименьшими потерями времени и мыслетоплива.

Что касается пользы от специализированных инструментов, то она сомнительна. Продавцы гербалайфа пакета Rational много лет утверждали, что только покупка их продуктов сделает ваши волосы длинными и шелковистыми проекты успешными. Типа, если аналитик не использует Rational Rose, то он и не аналитик вовсе. "Господа, его вообще сюда пустил?".

По этой теме у Григория есть несколько отличных статей:
"Убийцы времени" https://www.greesha.ru/articles/%D1%83%D0%B1%D0%B8%D0%B9%D1%86%D1%8B-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8/
"Простые инструменты" https://www.greesha.ru/articles/%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%8B%D0%B5-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/
И особенно: "Семь смертных грехов аналитика. Gula" https://www.greesha.ru/livejournal/%D1%81%D0%B5%D0%BC%D1%8C-%D1%81%D0%BC%D0%B5%D1%80%D1%82%D0%BD%D1%8B%D1%85-%D0%B3%D1%80%D0%B5%D1%85%D0%BE%D0%B2-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-gula/


-- Презентация ------------------------------------------
Что касается совместного обсуждения большой диаграммы (100+ элементов 200+ связей).
* Лист ватмана.
* Напечатать множество листов и склеить в лист А2 - А0, если нет большого принтера.
* Возможно, когда нибудь в переговорке станет нормой монитор (телевизор) 60+ дюймов, с сенсорным экраном, развернутый вертикально.

Есть еще неплохой вариант продемонстрированный Эли Шрагенхаймом в книге "Управленческие дилеммы"

-- Сложности восприятия ------------------------------------------
Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

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

71

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 03 Марта 2016, 12:21:54 »

Ссылка на доклад: https://www.youtube.com/watch?v=zVtTrXcHH2M

72

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 03 Марта 2016, 12:20:50 »

При этом почему вы не рассматриваете ТЗ как инструмент сдерживания "буйной фантазии" заказчика? 

Это имеет смысл, если нет более простых способов сдерживания буйной фантазии. Но эта тема за пределами доклада.

73

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 02 Марта 2016, 15:16:54 »

Об этом же, кстати, ГОСТ 34.

А вот это предлагаю внести в методические рекомендации по использованию ГОСТ от <придумайте от кого>:

Не рекомендуется включать ВИ в ТЗ по ГОСТ 34. ... и 19. ...

74

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 02 Марта 2016, 12:07:15 »

Григорий, Humbert, Леонид, спасибо за конструктивное обсуждение.

Некий итог.
1. Я кажется понял, где мы с Григорием разошлись в терминологии. Я имел ввиду, что зависимости могут быть и в другую сторону. И тогда возможно появление петель положительной обратной связи.
2. Данная диаграмма призвана ответить на вопрос "Why" (почему, зачем), причем, скорее, "Почему". В этом смысле она не конкурирует за место под солнцем с диаграммами отвечающими на вопрос "Как".
3. Теоретически она полезна.
4. Практическое ее применение сильно ограничено причинами, указанными Humbert и Леонидом. Даже не знаю чьи формулировки мне нравятся больше.

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

PS. Другие диаграммы предлагаю обсуждать в других ветках.

75

Обсуждение статей / Re: Статья "Трассировка требований разных уровней"

« : 29 Февраля 2016, 18:07:28 »

Связей, наверное, должно быть больше.

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

И связей больше и квадратиков больше.
1. Для иллюстрации подхода "правильная схема" была не нужна.
2. Для иллюстрации подхода "правильная схема" была вредна. То,  что Леонид нашел ошибку в схеме как раз и показывает, зачем она нужна. Вот если бы никто не нашел ошибки, то это означало бы, что она не нужна.

Ну а в целом - нормальная такая трассировка. В таком (графическом) виде применима при очень небольшом количестве требований и взаимосвязей, оптимально - на уровне презентации. При детализации превращается в нечитаемую паутину.

На уровне слайда такую схему хорошо делать, если вы собираетесь кому-то что-то втюхать. Ибо для "улучшения" восприятия, вы уберете все неприятные моменты.

Для анализа нужно работать с полной схемой. И проблема тут не в том, что она нечитаема. Читаема, просто времени нужно несколько больше.
Проблема в отрицательной обратной связи в нашей индустрии. За нахождение ошибок в таких схемах "тестировщику" создавали неприемлемые условия и он уходил. Теперь никто такие схемы не анализирует.
Итог: "Даже если вам повезет, и среди тысячи сотрудников вашей фирмы найдется кто-то, способный такую схему нарисовать, то прочитать ее будет некому. Второго сотрудника такой квалификации ваша фирма себе позволить не может." Если нужен пример, он есть у меня. Фирма 5000+ сотрудников.