#блоксхема #мойопыт #капитаночевидность #капитанНЕочевидность #мысливслух #нотации #системныйанализ

Блок - схема, недооцененная диаграмма, или универсальный инструмент?

Я люблю блок-схему и считаю одним из самых универсальных инструментов. И как всегда, тут важно понимать правила применения. Так как в институте у меня не было uml, bpmn и других нотаций, много было блок-схем, и нас гоняли по ним и по ГОСТу построения подобных диаграмм. И не зря!

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

Так ли это?
Посмотрим вглубь.
✅1.Я больше не знаю российских ГОСТов, в которых бы так хорошо описывались нотации, как это сделано по блок-схеме.
✅2.Название то какое! Это схема из блоков) с чёткой типизацией блоков.
✅3.Это визуализация графа, в основе которого лежат сети Петри и планарный граф. А граф мы можем применить для описания алгоритма.
✅4.Ну и не дураки всё таки придумали визуализацию алгоритмов (так я конечно про любую нотацию могу сказать))).
✅5.Это первая диаграмма, которую использовали для описания алгоритмов, которые уже превращали в код (если это не так, то расскажите мне дополнительно).

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

Блок-схема имеет правила составления, что даёт нам возможность достаточно чётко разложить процесс.
Попробую эти правила описать:
✅1.У блок-схемы всегда есть начало и конец, это единственные элементы, в которых допускается изображение разрыва потока.
✅2.Каждый элемент - это шаг процесса, а они чётко определены гостом и операциями, которые допустимы в ЭВМ:
👉ввод/вывод,
👉действия,
👉логический блок,
👉печать,
👉подпроцесс (процедура).
Есть ещё дополнительные блоки: цикл, документы, соединитель, комментарии.
Даже если вы по такой классификации разложите шаги процесса уже будет очень мощно! Что вцелом даёт возможность далее и функционую архитектуру решения более чётко описать.
✅3.Я написала про планарный граф, это правило нам говорит о том, что наша Блок-схема должна минимально иметь пересечения линий (а лучше вообще не иметь пересечения, если они есть, что-то не так с проектированием). Отличное ограничение, которые в любой нотации стоит держать в голове.
✅4.Правило "шампура", мы должны создавать шаги процесса так, чтобы у нас был основной поток, и изображение диаграммы похоже на нанизывание кусочков шашлыка на шампур. Ветки и пелти могут уходить в блок и возвращаться в основной процесс.
✅5.Чаще всего диаграмма идёт сверху в низ. Слева направо мне не очень нравится такие диаграммы рисовать и читать.
✅6.Если у нас получается очень длинная диаграмма, то возможно стоит задуматься о том, чтобы процесс делить на этапы и выделять процедуры. Учиться видеть, какие куски процесса можно переиспользовать и выделять их в подпроцессы, процедуры, описывать отдельно.
✅7.В диаграмме не должно быть разрывов. Нужно проверять правила, что из блока не должно быть несколько выходящих стрелок, допустима только одна. Если вам нужно ветвление, нужно воспользоваться логическим блоком.
✅8.Обязательно проверять диаграмму на скрытые циклы, где нарушена логика операций и процесс может зациклится.
✅9.В логическом элементе условие и стрелочки должны быть подписаны. При этом это логика, то есть вопрос должен быть локаничен и иметь ответы "да" - "нет".
✅10.Мы рисовали подобные диаграммы на листе бумаги, по правилу, что каждый блок расположен под другим и имеют одинаковую ширину и высоту, что тоже учит формулировать текст шага так, чтобы он уместился в блок, был понятен, и одновременно локаничен.

Команда считает, что ей не нужен аналитик.

#мысливслух #зачеманалитик #историиизжизни #развитие #чтоделать #мойопыт #ИТаналитик #проект #намненуженаналитик

А ещё можно накинуть - нам не нужна документация, мы итак без неё хорошо жили. Или пусть аналитик документирует то, что уже разработали. Правда что!!! Он же нам не нужен!!!

В каждой подобной фразе отдаётся боль.

Годы идут, но проблемы в отрасли те же самые. На тему "Зачем проекту аналитик?" я уже делала вебинар вместе с Евгением Галактионовым, рекомендую к просмотру, если у вас возникают подобные проблемы с командой, возможно какие-то мысли и инсайты для себя поймаете - https://www.youtube.com/live/sIi1JdB4Iow?feature=share

Но ещё я порассуждаю на эту тему.
Что же делать?

✅ 1.Хочется бежать из такой команды. И отчасти вы будете правы. Во-первых, если команда не работала никогда с аналитиком, а вот его наняли и вы такой красивый пришли и вот сейчас как заживём по-другому! То нет. Люди очень не любят перемены и изменения. С изменениями нужно работать и не всегда опыта, компетенций, да и вообще полномочий хватает аналитику. И часто не задача аналитика заниматься внедрением изменений внутренних процессов, хотя ему её могут поставить, и потом сказать, но ты же не справился.
✅2.Во вторых, не соглашаетесь писать требования после разработки продукта. Восстановить требования можно, но часто руководство воспринимает аналитика, как технического писателя, который "подтирает за командой" или администратора проекта. "Поздно пить боржоми, если почки уже отказали." Смысл работы аналитика теряется, и это первый шаг к выгоранию, делать не свои обязанности. А как быть? Аналитик должен опережать разработку, иначе выгода от его наличия на проекте теряется. Аналитик нужен для минимизации риска переделок на финише, и приближения результата к той проблеме и к тому эффекту, что хочет заказчик. Берите задачи с опережением спирта хотя бы на 0.5 спринта, а лучше на целый спринт вперёд, чтобы на планирование или груминге можно было получить от команды глубокие вопросы и более чёткую оценку по реализации задачи.
✅3."Нам не нужна документация, мы итак же без неё хорошо жили." Рост сложности проекта неизбежен, и вопрос с артефактами появится. Аналитик не технический писатель и он проектирует решение. Документация ради документации никому не нужна, кроме ситуаций с политическими играми в защите проекта. А спроектированные решения, костяк артефактов, и описание требований - это, то что необходимо для выравнивания контекста при общение с заказчиком и командой. Все должны быть в одной плоскости общения, чтобы исследовать проблему, спроектировать решение и приблизить проект к успеху.
✅4.Плюс - если ваша команда на удаленке - вам нужны артефакты, диаграммы, и вики проекта, для постоянного выравнивания общего контекста и коммуникации команды. Команда на удаленке часто получает проблему в коммуникации. Какие артефакты вам нужны и в каком объёме и на каком уровне детальности - решает команда и всё зависит от уровня компетенции участников, критичности и сложности проекта. Про артефакты, примерный их набор можно посмотреть в вебинаре "Пирамида артефактов" - https://www.youtube.com/live/Ua19ythnFvE?feature=share
✅5.Если уж давать, советы, то следующий совет - абстрагироваться от наездов команды и делать своё дело, желательно при этом подкрепляя всю свою деятельность поддержкой руководства (иначе работать с изменениями бесполезно). Всё таки вас зачем-то взяли на проект и поставили задачи? Чаще всего разговоры бесполезны, лучше показать результат своей работы. Вы же новый человек и уважение ещё нужно заслужить делами. Команда может молчать. Я как-то столкнулась с тем, что я зафиксировала решение несколькими диаграммами, спросила команду "Ну как? Что вам было полезно?" Все промолчали, а потом на ретро после спринта в самое хорошее за спринт записали мои диаграммы. Я была удивлена, и сделала вывод, что за молчанием может скрываться, что угодно, не стоит себя раскачивать фантазией.

Проект не нужен заказчику.

#мысливслух #мойопыт #менторство #проект #чтоделать #рассуждения #ненужнозаказчику

Уже года 4, я провожу оценку аналитиков в виде игры по сбору требований. Игра у меня родилась из большого количества собеседований, доклада Ольги Азимбаевой (можно почитать и посмотреть тут https://t.me/start_in_IT/233 ) и моего опыта.
Я имитирую типичного заказчика, погружаю аналитика в его обычную среду "сбора требований и общения с заказчиком". Цель выявить основные Паттерны поведения аналитика, посмотреть какие вопросы он задаёт заказчику, как собирает требования, какие требования, на что обращает внимание, насколько идёт за заказчиком и тем решением, которое ему приносит заказчик.

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

И вот в очередной раз, играя в такую игру менти мне задала вопрос, а как быть, если ты понимаешь уже на старте, что решение не решает проблем заказчика и ему это всё не нужно, и компания просто качает из него деньги?

Очень сложный вопрос. У меня нет однозначного ответа. Тут скорее, как в личной жизни, когда ты видишь, что в отношениях идёт обман, и один паразитирует за счёт другого. Что делать? Часто говорить бесполезно. Да и кто ты такой, чтобы это говорить? Этот опыт нужно получить.

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

Чем меньше опыта, тем меньше ты видишь эти игры. И как говорится, крепче спишь. С другой стороны, решение принято, исходя из чего, мы чаще всего не знаем, оно могло быть просто политическим, и путь развития идёт, хоть и криво, странно. На этом заведомо провальном проекте, тоже можно научиться, и часто даже большему. Многих product manager так и отбирают на собеседованиях, по умению справляться с провалами.

И нужно понимать, что ты делаешь и для чего. На старте или в момент growth haking, команда изначально делает, то что могут выкинуть. И просто проверяет гипотезы. Грамотный менеджер должен понимать, что специалист не может постоянно делать то, что будет выкинуто или положено в стол. И нужно проводить ротацию команды growth haking.

Вспомнила ещё книгу "Русская модель управления" ( https://t.me/start_in_IT/176 ), когда я вижу какие-то очень странные, по-моему мнению движения, реализации, я начинаю спрашивать "почему так?" Вспоминаю книгу и отвечаю, аааа вот почему.

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

Всегда есть выбор, даже если кажется, что его нет)

С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)

Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.

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

Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)

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

Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)

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

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

#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ

А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇

Ошибки проектирования сценариев взаимодействия систем при их интеграции.

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

А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.

Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.

И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?

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

Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?

И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.

И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.

И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.

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

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

#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы

P. S. Моё предложение в силе разобрать вашу sequence диаграмму)

Квотирование в интеграции, что это такое и зачем нужно?

Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.

Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.

✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.

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

Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).

Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.

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

#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции

А какие вы встречали кейсы Квотирования в своей практике?

Делитесь в комментариях ниже 👇

Концептуальное проектирование

Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.

Первая это Концептуальное проектирование (сюда же DFD отнесу), а второе - это блок-схемы, с помощью которых можно и алгоритм описать и процесс, и сделать это хорошо!

Сегодня решила написать про Концептуальное проектирование.

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

Но, в чем трудность?
✅1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
✅2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.

DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))

По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных

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

К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень

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

Мне нравится статья по этой теме в школе системного анализа и проектирования.

Рекомендую к применению на проектах)

#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст

Записала разбор sequence диаграммы.

Примем тот факт, что автор, никогда не делала раньше sequence диаграмм.
Будет полезно для начинающих и не только. Вдруг ещё что-то заметите, что бы можно было улучшить?)

#sequence #uml #системныйанализ #системныйаналитик #интеграция #разбор

https://youtu.be/JiJDt-jWFtY

Требования - это же не rocket science, что тут сложного?

Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.

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

Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!

✅ Требования - это ключевая единица результата работы аналитика.

По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.

Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).

Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг

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

#работастребованиями #системныйанализ #системныйаналитик #требования

Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇

Я боюсь, что разработчики решат, что я дурачок.

Аналитики перфекционисты, и возмутители спокойствия одновременно.

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

Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎

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

Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"

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

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

Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.

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

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

А вы какие используете катализаторы в работе?

#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований