Обновить
4
0
Вадим Животовский@tempart

Аналитик

Отправить сообщение

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

Недавно посмотрел про архитектуру Спорт-мастера https://www.youtube.com/watch?v=Ao7xqs_oX9s , там стройно и в целом понятно показана логика работы архитекторов. Вот в примерно в таком бы виде, где и как ваша ИБ-архитектура живёт, было бы супер

Из статьи не понял, а лезть в стандарт лень - E.123 допускает оба варианта?:

(в начале статьи, и почему-то 9 цифр без кода страны)

+12 345 678 901

(в середине статьи)

+123456789012

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

Получается, у вас ограничения не являются частью требований и живут отдельной жизнью? Что тогда включает в себя "требование"?

Спасибо, показано понятно и доступно.

Но есть проблемы таких простых примеров. И я не понимаю, как аналитики их решают.
Если вернуться в реальность, то покупатель обычно платит или в технологическом окне баристы, или уже по получению кофе. Потому что если вы хотите, чтобы в следующий раз покупатель пришёл к вам, то вы сначала запустите небыстрый процесс приготовления кофе, а не процесс оплаты.
Теперь самое весёлое - попробуйте показать эти три альтернативные оплаты на диаграмме. Ну хотя бы две. Я даже не прошу быть ещё ближе к реальности, когда обычно есть ещё участник в виде отдельного (мобильного) платёжного терминала, который вынесен к покупателю.
Вот за это не люблю Sequence. Читабельно только для самых простых сценариев, и не дай бог там альтернативы, затрагивающие процесс всего сценарий. Про негативные сценарии тут вообще лучше забыть

Мне вот интересно, а кто-нибудь вообще вчитывался в эту статью?

Это общее правило: с событием не связывается ни один элемент, кроме функции

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

правило, которому нужно придерживаться на 100%: логические решения могут приниматься только при выполнении функции

Дальше в тексте есть пример применения логического решения после события, а не функции.
Не понял.

Логический элемент «И». Когда для выполнения функции требуется одновременное выполнение нескольких событий:

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

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

А может и не вызвать, что ли?

В общем, устал я это читать. Думал быстренько понять про EPC, а тут такое...

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

Продуктовая аналитика. 1. События

Более традиционно принято это показывать в виде схемы (бизнес-)процессов на этапе формирования ФТ. Помогает и ФТ точнее формулировать, и, если надо, то показывать логику появления событий, их результат. Метрики - это уже одно из применений схемы, а не причина появления такой схемы.
Читать события в табличке без из визуализации я б не осилил :)

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

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

А тут мы уже про пользовательский опыт. Понятно, не все попадают аудиторию этой фичи. Свой возможный профит я уже описал. Не, реально, за несколько дней через тебя проходят сотни сайтов, доков, папок в компе, постов в десятках (даже сотнях) чатиках. Потом что-то найти - трэш, времени убивается очень много. Пусть сработает 0.1%, но если он мне сэкономит десятки минут, то это будет оправдано.
256ГБ - не проблема, особенно, если можно указать вручную диск. Но уже года 3 я системные SSD ставлю не менее 1ТБ (стандартно - 2), в т.ч. во всех своих ноутах

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

В принципе, выше уже заметили, что и без этой фичи тонны ваших данных летят хрен знает куда. Здесь, так понял, локально обрабатывается.
Но, соглашусь, безопасность проще обеспечить в своей контролируемой системе (= облаке Microsoft), чем на зоопарке пользовательских компов в окружении зоопарка софта и интересных действий пользователя

Жаль, на 10-ку не поставить, а переходить на 11-ю пока не готов. Мне такая фича поиска по истории, без перекапывания кучи всяких хистори, букмарков, папок и пр., очень пригодилась бы)

(а тут будет обидное для комментаторов к статье - читая некоторые комменты, ощущаю себя в обществе каких-то старпёров и шизофреников)

Статья зашла тяжело.

Если приводятся определения из каких-то отраслевых доков (Business Rules Group), то надо их излагать человеческим языком. Иначе издевательство над читателем вникать в этот канцеляризм.

Язык описания требований к системе бизнесу непонятен

Постоянный посетитель...

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

Постоянный посетитель должен иметь возможность отложить для себя 10 книг.

Значит, 9 книг он уже не вправе отложить. И здесь вы тоже уверены, что бизнес не должен увидеть этой фразы, чтобы он, не дай бог, не увидел галиматью в БТ?

В описании бизнес-правил не должны использоваться технические термины.

Серьёзно? Не надо путать глоссарий бизнеса и глоссарий ИС - и там, и там используются технические термины, но их значение формируется контекстом применения

Бизнес-правило должно описывать правило бизнеса

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

И нескромный вопрос. Вижу подпись "Системный аналитик". Но статья про бизнес-анализ, где чётко выделена роль "бизнес-аналитик" в качестве актора всего этого безобразия.
Тут или крестик снять, или штаны надеть. Зачем выкладывать статью по теме, где автор не является специалистом?

За много лет так и не смог привыкнуть к TC. Использовал его последние пару лет для переименования папок, но и тут нашёл альтернативу. Интерфейс для гиков, технарей.

Ну что ж вы так! Люди старались же. Навялили текст, отшлифовали его до состояния протекания между пальцами, под видом "Мнение" продвинули саморекламу, освоили рекламный бюджет. А вы вот взяли и всё обесценили! Глядишь, товарищи так и премию не получат - придётся опять ляпать тексты, а нам придётся отвлекаться на всякую чушь. Лучше похвалите их, проявите свои софтскилы поглаживания - все будут довольны

В статье раздел "Бизнес-логика" по содержанию больше похож на системную логику

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

Нет желания дальше раскрывать сказанное - это очень долго. Для начала: BPMN - это не методология, это нотация. Если в вашей компании не понимают разницы, то дальше просто нет смысла в диалоге

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

Пытаюсь понять практическое применение.
Можете привести любой реальный или потенциально исполняемый кейс улучшения бизнес-процессов на основании результатов этой работы?

Если оставить в стороне политику, кто из конкурентов сможет стать достойной заменой Касперскому?

Например, недавно несколько дней попробовал поработать с Bitdefender (Family Pack). Ну это треш. Насколько костерил Касперского, но всё познаётся в сравнении.
Пробный период активировался не с момента запуска или установки программы, а с момента запуска инсталлера (сразу мною прерванного).
Пользовательские интерфейсы - немасштабируемые окошечки (привет 2000-м).
Настроек меньше, чем в Касперском - не все нужные нашёл.
Невозможен экспорт/импорт настроек (пусть пользователь поработает обезьянкой на остальных компах).
В ЛК не обнаружил никакого упоминания и доступа к открытому тикету. "Мы ответили, тикет закрываем" безо всякого ответа и ссылки на тикет - это круто. Ответ прислали после оценки работы, т.е. после закрытия тикета. И тоже без ссылок

конкретнее?

Как и проект может быть частью процесса, так и процесс может бысть частью проекта.
Про "простое отличие" "проект это один из видов процесса"

Хорошее начало для статьи, пытающейся систематизировать оба понятия:

Однако, отличие процесса от проекта – простое, проект это один из видов процесса

  1. Вид какого процесса? Бизнес-процессы - это повторяющиейся действия. Проект - это однократное мероприятие

  2. Проект, в свою очередь, состоит из процессов.

Сплошной "Малкович, Малкович"

В целом здравая статья, немного книжно-пафосная.
Есть несколько мыслей:

  1. Из вводных данных непонятно, откуда так сразу у БА появилась конкретная задача - внедрить BI. Раньше думал, что БА проводит обследования/исследования, и уж потом выбирается инструмент (BI - инструмент, а не цель). Не вижу точно сформулированных проблемы (перечислено as is, и?), цели - чего вдруг БА внезапно должен внедрять BI?

  2. Перефразировать понятное, измеряемое значение "рентабельность продаж" в нечто аморфное "эффективность продаж" - вряд ли это надо делать БА. Ну только если ради броского слова для презентации

  3. Задавать вопрос "Как он поможет вам улучшить бизнес-процессы?" какому-то неопределённому стейкхолдеру - не надо. Вам опять покрасоваться, или вы, всё-таки, профессионал и собираетесь говорить со стейкхолдером на его языке?

  4. "не принимайте чью-либо сторону". Туманное описание. Вы, как БА, обязаны выработать путь решения - вас для этого наняли, а не для поиска общих знаменателей. Решение означаете достижение поставленной бизнес-цели, а не лавирование между кем-то и кем-то. Т.е., вроде всё правильно написано, но написано так, как будто это аксиома. Способы поиска решения не всегда подразумевают "мир, дружба, жвачка", к сожалению

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Системный аналитик, Бизнес-аналитик
От 250 000 ₽
Описание бизнес-процессов
Бизнес аналитика