Что самое интересное в работе?
Мне часто задают такой вопрос, потому что я всем говорю, что очень её люблю)
Надеюсь каждый из вас тоже любит свою работу, но если вдруг вы захотите стать бизнес системным аналитиком, то вот вам "то самое" за что эта работа прекрасна для меня))
Начнем с того, что есть максимально размытое понятие между бизнес и системным аналитиком для работодателей, поэтому я говорю, что совмещаю обе эти роли, хотя есть то, чего я не делаю как СА: sql, postman, swagger.
А теперь о плюшечках:
1. Работа обычно удаленная, пожалуй этого хватит 😂🙈
Но, ладно, продолжим))
2. Общение с клиентами, которые посвящают в свои разные профессии, и я смотрю глазами разных людей каждый день👀 это действительно интересно, как будто я каждый день меняю работу - сегодня строитель, завтра управляющий компании, послезавтра юрист, и так далее))
3. Вытаскивание из этих клиентов необходимых требований и борьба с не реализуемыми, это тоже интересно и придает такую изюминку в работе, диалог - дискуссия - убеждение))
4. Отрисовка схем, когда они становятся длиннее, ещё длиннее, заканчивается лист А4, то кажется ты выполняешь такую огромную работу, которая будет полезна разработчикам. Первое - видимый результат работы, второе - программист знает все пути функции, как работает, что и зачем))
5. Прорисовка в Figma - это тоже отдельный вид удовольствия, я создаю дизайн, который потом воплотят в жизнь, и все текстовые требования превращаются в красивые картинки, которые можно показать клиенту и он тоже будет восторженно ждать воплощения))
6. Тестирование и показ клиенту конечного результата, созданное программистами🙈 как же кайфово получать фидбэки (я их передаю потом всей команде) во время разговора, понимаешь, что работа была проделана отлично)
#системнаяаналитика #клиент #системныйаналитик #systemanalysis #analysis #businessanalytics #бизнесаналитик #бизнесаналитика #люблюработу #работа
Мне часто задают такой вопрос, потому что я всем говорю, что очень её люблю)
Надеюсь каждый из вас тоже любит свою работу, но если вдруг вы захотите стать бизнес системным аналитиком, то вот вам "то самое" за что эта работа прекрасна для меня))
Начнем с того, что есть максимально размытое понятие между бизнес и системным аналитиком для работодателей, поэтому я говорю, что совмещаю обе эти роли, хотя есть то, чего я не делаю как СА: sql, postman, swagger.
А теперь о плюшечках:
1. Работа обычно удаленная, пожалуй этого хватит 😂🙈
Но, ладно, продолжим))
2. Общение с клиентами, которые посвящают в свои разные профессии, и я смотрю глазами разных людей каждый день👀 это действительно интересно, как будто я каждый день меняю работу - сегодня строитель, завтра управляющий компании, послезавтра юрист, и так далее))
3. Вытаскивание из этих клиентов необходимых требований и борьба с не реализуемыми, это тоже интересно и придает такую изюминку в работе, диалог - дискуссия - убеждение))
4. Отрисовка схем, когда они становятся длиннее, ещё длиннее, заканчивается лист А4, то кажется ты выполняешь такую огромную работу, которая будет полезна разработчикам. Первое - видимый результат работы, второе - программист знает все пути функции, как работает, что и зачем))
5. Прорисовка в Figma - это тоже отдельный вид удовольствия, я создаю дизайн, который потом воплотят в жизнь, и все текстовые требования превращаются в красивые картинки, которые можно показать клиенту и он тоже будет восторженно ждать воплощения))
6. Тестирование и показ клиенту конечного результата, созданное программистами🙈 как же кайфово получать фидбэки (я их передаю потом всей команде) во время разговора, понимаешь, что работа была проделана отлично)
#системнаяаналитика #клиент #системныйаналитик #systemanalysis #analysis #businessanalytics #бизнесаналитик #бизнесаналитика #люблюработу #работа
🔥4❤1🥰1
В прошлый раз я рассказала, что рисую в Figma и это так))
Не всегда на проекте присутствует дизайнер, поэтому считаю важным использование такого инструмента. Фигма очень сильно облегчает жизнь, там просто создаются экраны, всего лишь нажали букву F и вам доступны и макбуки, и длинные ноуты, и даже мобильные устройства разных размеров)
Когда мы создали наш экранчик, а он естественно не один, нужно нарисовать наше приложение поэтапно, с самого начала.
Вообще, если вы новый аналитик на проекте и первый, а приложение уже есть, просто с самого начала работы - перерисуйте себе в фигму все экранчики, вам будет гораздо проще делать доработки, что-то двигать в существующих экранах и показывать это фронтендерам)
После того, как мы создали с помощью текста, квадратиков, прямоугольников и прочих фигур что-то похожее на приложение, самое главное - соедините экраны, сделайте переходы!!
Это очень важно, это плюшка фигмы, когда вы соединяете экранчики, и люди могут просто перейти по ссылке и играть как будто в реальном интерфейсе:)
P.s. не аналитики, не программисты - ВЫ МОЖЕТЕ СОЗДАТЬ СЕБЕ ИГРУ ЗА ПАРУ МИНУТ)))
Нажимаем на нашу фигурку или текст, в режиме prototype и ведём к другому экрану. Будет переход на целый экран.
Нажимаем на нашу фигурку и ведём к другому экрану, настраиваем, что это modal (модалка), тогда можем сделать всплывающее окошко в приложении, не забываем поставить закрытие на нажатие в пустоту, или ограничить и нажимать обратно лишь через отмену(крестик).
Пошагово можете посмотреть это в картинках)
Надеюсь вы сможете воспользоваться этим прекрасным приложением, и хотя бы просто побаловаться для себя)) А аналитики - тренируйтесь, создавайте чаще в этом приложении, и вы будете рисовать прототипы буквально во время разговора с клиентом (чем я обычно и занимаюсь 😁👍)
Самая простенькая игрушка, которую когда-то я придумала вместе с другом (Можете попробовать пройти, там правда есть конец с котиком)) - https://www.figma.com/proto/4J3lZAcoOPWtdw5o0MTrrr/Untitled?page-id=0%3A1&node-id=2-126&viewport=-61%2C969%2C0.38&t=cuDiSPfhRQpRYcxp-1&scaling=scale-down&content-scaling=fixed&starting-point-node-id=2%3A126
(С компьютера легче играть, а на телефоне двигается экран вниз, там кнопочки будут - без них не выиграть))
#Figma #учу_рисовать #бизнес_аналитик #системный_аналитик #системнаяаналитика #бизнесаналитика #клиент #прототипирование #прототип #дизайн
Не всегда на проекте присутствует дизайнер, поэтому считаю важным использование такого инструмента. Фигма очень сильно облегчает жизнь, там просто создаются экраны, всего лишь нажали букву F и вам доступны и макбуки, и длинные ноуты, и даже мобильные устройства разных размеров)
Когда мы создали наш экранчик, а он естественно не один, нужно нарисовать наше приложение поэтапно, с самого начала.
Вообще, если вы новый аналитик на проекте и первый, а приложение уже есть, просто с самого начала работы - перерисуйте себе в фигму все экранчики, вам будет гораздо проще делать доработки, что-то двигать в существующих экранах и показывать это фронтендерам)
После того, как мы создали с помощью текста, квадратиков, прямоугольников и прочих фигур что-то похожее на приложение, самое главное - соедините экраны, сделайте переходы!!
Это очень важно, это плюшка фигмы, когда вы соединяете экранчики, и люди могут просто перейти по ссылке и играть как будто в реальном интерфейсе:)
P.s. не аналитики, не программисты - ВЫ МОЖЕТЕ СОЗДАТЬ СЕБЕ ИГРУ ЗА ПАРУ МИНУТ)))
Нажимаем на нашу фигурку или текст, в режиме prototype и ведём к другому экрану. Будет переход на целый экран.
Нажимаем на нашу фигурку и ведём к другому экрану, настраиваем, что это modal (модалка), тогда можем сделать всплывающее окошко в приложении, не забываем поставить закрытие на нажатие в пустоту, или ограничить и нажимать обратно лишь через отмену(крестик).
Пошагово можете посмотреть это в картинках)
Надеюсь вы сможете воспользоваться этим прекрасным приложением, и хотя бы просто побаловаться для себя)) А аналитики - тренируйтесь, создавайте чаще в этом приложении, и вы будете рисовать прототипы буквально во время разговора с клиентом (чем я обычно и занимаюсь 😁👍)
Самая простенькая игрушка, которую когда-то я придумала вместе с другом (Можете попробовать пройти, там правда есть конец с котиком)) - https://www.figma.com/proto/4J3lZAcoOPWtdw5o0MTrrr/Untitled?page-id=0%3A1&node-id=2-126&viewport=-61%2C969%2C0.38&t=cuDiSPfhRQpRYcxp-1&scaling=scale-down&content-scaling=fixed&starting-point-node-id=2%3A126
(С компьютера легче играть, а на телефоне двигается экран вниз, там кнопочки будут - без них не выиграть))
#Figma #учу_рисовать #бизнес_аналитик #системный_аналитик #системнаяаналитика #бизнесаналитика #клиент #прототипирование #прототип #дизайн
🔥1
Miro или очень удобный инструмент для всех (не только аналитикам)
Долго думала, что же ещё опубликовать на этом канале, ощущение, что я раскрыла уже все темы, остальное лишь глубокое погружение...)
(Если у вас есть идеи, что бы вы хотели узнать от аналитика, то добро пожаловать в личку))
Но, сегодня, меня спросили: Где удобнее всего писать заметки, вести календарик сотрудников и что-то подобное?
На ум пришло много бесплатных приложений для заметок, и одно из них это Miro😍
Приложение устанавливается и на телефон, и в браузер (синхронизация полная).
Очень вам советую попробовать его в действии)
Можно писать заметки или использовать различные шаблоны(канбан, расписание, и много-много других классных идей, даже для принятия решений), для удобства))
Доска бесконечная, на ней можно располагать все что угодно (рисунки, файлы, стикеры, диаграммы и т.д.).
Ей можно пользоваться вместе с друзьями.
На ней можно показывать презентации, в которых люди будут взаимодействовать друг с другом)
Единственный минус это английский интерфейс😢
Этот инструмент практически полностью бесплатный, но там нельзя создать больше 3 досок ( это не беда, ведь доски бесконечные))
#miro #инструмент #systemanalytics #бизнес_аналитик #бизнесаналитика #учу_рисовать #планирование
Долго думала, что же ещё опубликовать на этом канале, ощущение, что я раскрыла уже все темы, остальное лишь глубокое погружение...)
(Если у вас есть идеи, что бы вы хотели узнать от аналитика, то добро пожаловать в личку))
Но, сегодня, меня спросили: Где удобнее всего писать заметки, вести календарик сотрудников и что-то подобное?
На ум пришло много бесплатных приложений для заметок, и одно из них это Miro😍
Приложение устанавливается и на телефон, и в браузер (синхронизация полная).
Очень вам советую попробовать его в действии)
Можно писать заметки или использовать различные шаблоны(канбан, расписание, и много-много других классных идей, даже для принятия решений), для удобства))
Доска бесконечная, на ней можно располагать все что угодно (рисунки, файлы, стикеры, диаграммы и т.д.).
Ей можно пользоваться вместе с друзьями.
На ней можно показывать презентации, в которых люди будут взаимодействовать друг с другом)
Единственный минус это английский интерфейс😢
Этот инструмент практически полностью бесплатный, но там нельзя создать больше 3 досок ( это не беда, ведь доски бесконечные))
#miro #инструмент #systemanalytics #бизнес_аналитик #бизнесаналитика #учу_рисовать #планирование
🔥3😁1
Документация и ГОСТы..
Как часто вам приходилось читать пользовательскую инструкцию?
Наверное, ответ будет мимолётом на сложных продуктах или вообще никогда))
Все почему? Да потому что она не интересная, скучная, да и просто напросто до-ку-мент.
Что я вам предлагаю, чтобы заинтересовать ваших пользователей?)
Во-первых, создать сайт, красочный, яркий, может копирующий интерфейс вашей системы... Создать его можно как угодно, могу посоветовать docusaurus из простого))
Во-вторых, выпускайте обновления, пишите их в телеграмм клиентам, на сайте создайте страничку обновлений, и можете впихнуть в уведомления в самой системе))
А теперь ещё про сайтик:
1. Да, сайт будет похож на документацию, если используете docusaurus, но там есть следующие плюшечки:
-вставление гифок, где вы видели это в документе вордовском?)) это очень помогает юзерам, как именно нажимать и зачем, вместо 100 фотографий))
- гиперссылки
- фоточки
- сайт, открывающийся в любом браузере
- вы пишите каждую страничку в отдельном блокнотике и можете исправлять только его
- можно изменять странички, поменяв лишь одну цифорку
2. Можно использовать не docusaurus, а создать с нуля свой или на конструкторе.
Что вы можете сделать необычного?
- древо документа, чтобы проваливаться по дочерним блокам. Это как минимум понятно интерфейсно))
- вставить ваш интерфейс и подписать его с разных сторон, опять таки используя гиперссылки.
3. Не забывайте использовать тезаурус, и везде вставлять гиперссылки на слова. Как проверить поймут ли это слово? Спросите у третьеклассника, что оно значит, если не ответит - пишите в тезаурус))
Ну и один из сложных вариантов, на каждую фичу вам придется мучить программистов, но пользователи скажут вам спасибо))
Внедряем вопросик в систему, и когда его активирует пользователь - возле каждого поля, загорается вопросик, при нажатии на который - происходит обучение, что и как, зачем и почему))
Здесь можно облегчить им задачу - если вы будете прописывать текст почемучки с картинками, а они просто вставлять это в модалку на данный вопрос.
А можно усложнить - при нажатии на вопрос - происходит интерфейсное обучение, с нажатием на другие зависимые данные и получается какой-то результат.
#документация #документирование #сайт #дизайн #системнаяаналитика #системный_аналитик #бизнесаналитика #бизнес_аналитик
Как часто вам приходилось читать пользовательскую инструкцию?
Наверное, ответ будет мимолётом на сложных продуктах или вообще никогда))
Все почему? Да потому что она не интересная, скучная, да и просто напросто до-ку-мент.
Что я вам предлагаю, чтобы заинтересовать ваших пользователей?)
Во-первых, создать сайт, красочный, яркий, может копирующий интерфейс вашей системы... Создать его можно как угодно, могу посоветовать docusaurus из простого))
Во-вторых, выпускайте обновления, пишите их в телеграмм клиентам, на сайте создайте страничку обновлений, и можете впихнуть в уведомления в самой системе))
А теперь ещё про сайтик:
1. Да, сайт будет похож на документацию, если используете docusaurus, но там есть следующие плюшечки:
-вставление гифок, где вы видели это в документе вордовском?)) это очень помогает юзерам, как именно нажимать и зачем, вместо 100 фотографий))
- гиперссылки
- фоточки
- сайт, открывающийся в любом браузере
- вы пишите каждую страничку в отдельном блокнотике и можете исправлять только его
- можно изменять странички, поменяв лишь одну цифорку
2. Можно использовать не docusaurus, а создать с нуля свой или на конструкторе.
Что вы можете сделать необычного?
- древо документа, чтобы проваливаться по дочерним блокам. Это как минимум понятно интерфейсно))
- вставить ваш интерфейс и подписать его с разных сторон, опять таки используя гиперссылки.
3. Не забывайте использовать тезаурус, и везде вставлять гиперссылки на слова. Как проверить поймут ли это слово? Спросите у третьеклассника, что оно значит, если не ответит - пишите в тезаурус))
Ну и один из сложных вариантов, на каждую фичу вам придется мучить программистов, но пользователи скажут вам спасибо))
Внедряем вопросик в систему, и когда его активирует пользователь - возле каждого поля, загорается вопросик, при нажатии на который - происходит обучение, что и как, зачем и почему))
Здесь можно облегчить им задачу - если вы будете прописывать текст почемучки с картинками, а они просто вставлять это в модалку на данный вопрос.
А можно усложнить - при нажатии на вопрос - происходит интерфейсное обучение, с нажатием на другие зависимые данные и получается какой-то результат.
#документация #документирование #сайт #дизайн #системнаяаналитика #системный_аналитик #бизнесаналитика #бизнес_аналитик
🔥2
Use case
Один из инструментов для написания сценария.
Вы могли бы изобразить его с помощью uml, но если хочется отобразить словами, с возможными внесениями изменений, выделением начальной и конечной точки,.. то почему нет?)
Что нам нужно для этого? Нарисовать табличку в Ворде или ексельке) я приложила ее как картинку😊
А теперь рассмотрим каждое поле подробнее, как его заполнять:
1. Номер - Поле обязательно к заполнению, чтобы потом в тех задании просто ссылаться на UC-150, вместо написания длинного названия.
2. Название - напишите название сценария, один кейс - один сценарий. Нельзя пройтись полностью по системе. Необходимо выделять отдельные функции.
3. Автор - Оставьте свои контакты, на случай если другой аналитик что-то не поймет, или программист захочет с вами связаться.
4. Дата создания - Для актуальности таблички, необходимо запоминать ее дату создания
5. Возможно, вашу табличку захотят изменить, поэтому можно сразу добавить поле "Изменено кем (Дата изменения)", это поле совмещает в себе автора и дату, так же лучше прописывать какс вами связаться номер телефона или ссылка соц.сеть.
6. Действующие лица - это наши акторы (Нет, это не ошибка в слове, это обозначение действующего субъекта, действия которого направлено на других). Это может быть система, сервер, бд, пользователь 1, и пр. Тот, кто как-то влияет на данную функцию, с чем она связана.
7. Описание - краткое описание функции, обычно понятное из названия.
8. Предусловие - как оказаться перед этим функционалом? надо зайти в систему? или попасть на страничку? или нажать кнопку?
9. Постусловие - обычно это последнее предложение из основного потока. То, чего мы добились этой функцией.
10. Основной поток - Наш сценарий находится именно здесь, что делают акторы, что происходит. Нужно смотреть со всех сторон одновременно, это как пользовательская инструкция, юзер нажал кнопку, система сделала что-то, и т.д.
11. Альтернативные потоки - мое любимое, ведь не всегда юзер нажмет кнопку и система выведет то, что нужно, она может и упасть в ошибку. Если вдруг вы расписываете все ошибки, 401, 402, 403, то лучше их записывать в разные альтернативные потоки. Альтернативный поток должен содержать первую цифру из основного потока, и дальше использовать буковки. Если бы в моем рисунке был еще один альтернативный поток я бы показала его как 2.б. 2.б.1. и т.д.
Когда вас просят описать быстренько баг, а это кстати очень важно где-то хранить, чтобы потом к нему вернуться и проверить. Это один из реально помогающих способов, как же вы к этому пришли:)
Где использовать в реальной жизни?
Это может помочь с выбором решения, вы уменьшите табличку в несколько раз, оставив дату, название, основной поток и альтернативный.
В основном потоке вы распишите, что должно быть в этом варианте, в альтернативном, что может пойти не так. И так на каждый ваш вариант.
Вы максимально сможете продумать будущую ситуацию со всех сторон.
Поэтому пробуйте применять в реальной жизни, и не бойтесь рассматривать ошибки, чтобы недопустить их:)
#usecase #use_case #systemanalytics #bisunessanalys #принятиерешений #сценарий #функция
Один из инструментов для написания сценария.
Вы могли бы изобразить его с помощью uml, но если хочется отобразить словами, с возможными внесениями изменений, выделением начальной и конечной точки,.. то почему нет?)
Что нам нужно для этого? Нарисовать табличку в Ворде или ексельке) я приложила ее как картинку😊
А теперь рассмотрим каждое поле подробнее, как его заполнять:
1. Номер - Поле обязательно к заполнению, чтобы потом в тех задании просто ссылаться на UC-150, вместо написания длинного названия.
2. Название - напишите название сценария, один кейс - один сценарий. Нельзя пройтись полностью по системе. Необходимо выделять отдельные функции.
3. Автор - Оставьте свои контакты, на случай если другой аналитик что-то не поймет, или программист захочет с вами связаться.
4. Дата создания - Для актуальности таблички, необходимо запоминать ее дату создания
5. Возможно, вашу табличку захотят изменить, поэтому можно сразу добавить поле "Изменено кем (Дата изменения)", это поле совмещает в себе автора и дату, так же лучше прописывать какс вами связаться номер телефона или ссылка соц.сеть.
6. Действующие лица - это наши акторы (Нет, это не ошибка в слове, это обозначение действующего субъекта, действия которого направлено на других). Это может быть система, сервер, бд, пользователь 1, и пр. Тот, кто как-то влияет на данную функцию, с чем она связана.
7. Описание - краткое описание функции, обычно понятное из названия.
8. Предусловие - как оказаться перед этим функционалом? надо зайти в систему? или попасть на страничку? или нажать кнопку?
9. Постусловие - обычно это последнее предложение из основного потока. То, чего мы добились этой функцией.
10. Основной поток - Наш сценарий находится именно здесь, что делают акторы, что происходит. Нужно смотреть со всех сторон одновременно, это как пользовательская инструкция, юзер нажал кнопку, система сделала что-то, и т.д.
11. Альтернативные потоки - мое любимое, ведь не всегда юзер нажмет кнопку и система выведет то, что нужно, она может и упасть в ошибку. Если вдруг вы расписываете все ошибки, 401, 402, 403, то лучше их записывать в разные альтернативные потоки. Альтернативный поток должен содержать первую цифру из основного потока, и дальше использовать буковки. Если бы в моем рисунке был еще один альтернативный поток я бы показала его как 2.б. 2.б.1. и т.д.
Когда вас просят описать быстренько баг, а это кстати очень важно где-то хранить, чтобы потом к нему вернуться и проверить. Это один из реально помогающих способов, как же вы к этому пришли:)
Где использовать в реальной жизни?
Это может помочь с выбором решения, вы уменьшите табличку в несколько раз, оставив дату, название, основной поток и альтернативный.
В основном потоке вы распишите, что должно быть в этом варианте, в альтернативном, что может пойти не так. И так на каждый ваш вариант.
Вы максимально сможете продумать будущую ситуацию со всех сторон.
#usecase #use_case #systemanalytics #bisunessanalys #принятиерешений #сценарий #функция
🔥2❤1
Поговорим о разносторонности системных бизнес аналитиков)
Компаний сейчас очень-очень много, и это понятно)) но, каждая компания отличается от другой своими требованиями к сотрудникам.
Что мы можем увидеть на рынке для БА и СА?
Большие компании, в особенности финтех (приложение банков..), представляют так:
БА это человек, который смотрит пользовательский путь по логам, и из своих соображений понимает "почему пользователи не идут дальше в приложении?" - соответственно предлагает решения "как улучшить функционал" или "преобразовать дизайн", чтобы юзера дальше пользовались приложением. По факту для больших компаний БА не общается с клиентом, а просто подсматривает))
СА в больших компаниях это что-то далёкое от клиента и максимально похожее на программиста, он пишет запросы в БД, проектирует Rest api, расписывает uml на основе реальных запросов, предварительно просматривая их, например, в Charles, т.е. СА выполняет буквально написание кода, который можно скопировать с uml и остаётся чуть-чуть подредактировать))
Средние компании, не привыкли разделять БА и СА, им проще использовать одного универсального сотрудника.
Чем он занимается?
Общается с клиентами напрямую, обрабатывает требования, пишет их с помощью uml, use case, user story, bpmn и отдает программистам. Но речь о БД, проверки логов, и написании запросов на английском не идёт 😁 хотя не всегда) иногда универсальный сотрудник настолько универсальный, что делает все это, но мои опыт показывает, что здесь не требуются данные навыки)
Маленькие компании - не привыкли нанимать БА и СА на постоянку, у них есть программисты и им этого достаточно. Единственное, когда они обращаются за помощью - в самом начале - к фрилансерам или фирмам, которые оказывают услуги разработки приложения, там можно заказать только работы БА и СА, а можно сделать полностью приложение.
В таких компаниях вы будете каждый раз обрабатывать новые знания, сегодня юрист, завтра спортсмен, послезавтра сантехник (естественно сроки - 3 мес, полгода, год на разработку).
Здесь зависит все от вас, найдите компанию не продуктовую или идите на фриланс универсальным Б/С-А. Пишите проекты и зарабатывайте))
Подведем итоги, в зависимости от ваших навыков вы можете выбрать себе границы - в какие компании вам нужно обращаться, кому вы будете нужны, и что в себе прокачивать)
А ещё есть дата аналитик, это похоже на БА в больших компаниях, но там ещё больше цифр и отчётов, меньше кейсов и схем. Но это уже другая история и лучше смотреть курсы от Яндекса для них, они совсем другая сфера😁🙈
#БА #СА #бизнесаналитик #системныйаналитик #systemanalysis #systemanalyst #bisunessanalys
Компаний сейчас очень-очень много, и это понятно)) но, каждая компания отличается от другой своими требованиями к сотрудникам.
Что мы можем увидеть на рынке для БА и СА?
Большие компании, в особенности финтех (приложение банков..), представляют так:
БА это человек, который смотрит пользовательский путь по логам, и из своих соображений понимает "почему пользователи не идут дальше в приложении?" - соответственно предлагает решения "как улучшить функционал" или "преобразовать дизайн", чтобы юзера дальше пользовались приложением. По факту для больших компаний БА не общается с клиентом, а просто подсматривает))
СА в больших компаниях это что-то далёкое от клиента и максимально похожее на программиста, он пишет запросы в БД, проектирует Rest api, расписывает uml на основе реальных запросов, предварительно просматривая их, например, в Charles, т.е. СА выполняет буквально написание кода, который можно скопировать с uml и остаётся чуть-чуть подредактировать))
Средние компании, не привыкли разделять БА и СА, им проще использовать одного универсального сотрудника.
Чем он занимается?
Общается с клиентами напрямую, обрабатывает требования, пишет их с помощью uml, use case, user story, bpmn и отдает программистам. Но речь о БД, проверки логов, и написании запросов на английском не идёт 😁 хотя не всегда) иногда универсальный сотрудник настолько универсальный, что делает все это, но мои опыт показывает, что здесь не требуются данные навыки)
Маленькие компании - не привыкли нанимать БА и СА на постоянку, у них есть программисты и им этого достаточно. Единственное, когда они обращаются за помощью - в самом начале - к фрилансерам или фирмам, которые оказывают услуги разработки приложения, там можно заказать только работы БА и СА, а можно сделать полностью приложение.
В таких компаниях вы будете каждый раз обрабатывать новые знания, сегодня юрист, завтра спортсмен, послезавтра сантехник (естественно сроки - 3 мес, полгода, год на разработку).
Здесь зависит все от вас, найдите компанию не продуктовую или идите на фриланс универсальным Б/С-А. Пишите проекты и зарабатывайте))
Подведем итоги, в зависимости от ваших навыков вы можете выбрать себе границы - в какие компании вам нужно обращаться, кому вы будете нужны, и что в себе прокачивать)
А ещё есть дата аналитик, это похоже на БА в больших компаниях, но там ещё больше цифр и отчётов, меньше кейсов и схем. Но это уже другая история и лучше смотреть курсы от Яндекса для них, они совсем другая сфера😁🙈
#БА #СА #бизнесаналитик #системныйаналитик #systemanalysis #systemanalyst #bisunessanalys
🔥2
Вопросы, которые НЕ бессмысленно спрашивать)
Часто, мы не спрашиваем очевидные вещи, а аналитики общающиеся с клиентами делают это))
Топ любимых вопросов:
1. Правильно ли я понимаю, что вы имели ввиду вот это "перечисление того, что сказал оппонент"?
Раза два за тридцать минутный разговор надо дать понять человеку, что мы верно его поняли и если что он нас поправит)
2. Вы уверены, что это должно быть так, а не вот так?
То чувство,когда ты понимаешь, что его виденье не впишется в реалии системы и лучше сделать вот так😁 медленно подводим к своему мнению))
3. Расскажите, как вы представляете работу этого функционала по пунктам?
Не только аналитикам применима фраза, потому что любой план, любая идея должна быть проанализирована по мелочам до самого конца.
А для аналитиков сразу накладываются вопросы про ошибки: а уходить ли в ошибку на этом пункте, если юзер нажал не то? А как ему помочь? Развилки? Возврат?
4. Сможешь ли ты это сделать?
Это уже больше вопрос не к клиенту, а к программисту, если брать из работы аналитиков.
А в жизни - ко всем, кому обращаемся за помощью)
Да, надо быть уверенным, что если мы назначаем задачу на данного человека, то выполнит ли он ее и за сколько времени. Тут же оцениваем человекочасы)
А, возможно, ее упростят в разы, или же закидают подковыристые вопросы, которые усложнят задачу ))
5. Значит, мы делаем так и так?
А этот вопрос, чтобы были доказательства, лучше задавать письменно, после собрания, или под видеозапись)
Подведение итогов на согласование определенных работ.
Не всегда клиенты соглашаются с начальным видением, поэтому лучше подстраховаться и иметь запись "а вы говорили вот так"))))
#БА #СА #бизнесаналитик #системныйаналитик #systemanalysis #systemanalyst #bisunessanalys
Часто, мы не спрашиваем очевидные вещи, а аналитики общающиеся с клиентами делают это))
Топ любимых вопросов:
1. Правильно ли я понимаю, что вы имели ввиду вот это "перечисление того, что сказал оппонент"?
Раза два за тридцать минутный разговор надо дать понять человеку, что мы верно его поняли и если что он нас поправит)
2. Вы уверены, что это должно быть так, а не вот так?
То чувство,когда ты понимаешь, что его виденье не впишется в реалии системы и лучше сделать вот так😁 медленно подводим к своему мнению))
3. Расскажите, как вы представляете работу этого функционала по пунктам?
Не только аналитикам применима фраза, потому что любой план, любая идея должна быть проанализирована по мелочам до самого конца.
А для аналитиков сразу накладываются вопросы про ошибки: а уходить ли в ошибку на этом пункте, если юзер нажал не то? А как ему помочь? Развилки? Возврат?
4. Сможешь ли ты это сделать?
Это уже больше вопрос не к клиенту, а к программисту, если брать из работы аналитиков.
А в жизни - ко всем, кому обращаемся за помощью)
Да, надо быть уверенным, что если мы назначаем задачу на данного человека, то выполнит ли он ее и за сколько времени. Тут же оцениваем человекочасы)
А, возможно, ее упростят в разы, или же закидают подковыристые вопросы, которые усложнят задачу ))
5. Значит, мы делаем так и так?
А этот вопрос, чтобы были доказательства, лучше задавать письменно, после собрания, или под видеозапись)
Подведение итогов на согласование определенных работ.
Не всегда клиенты соглашаются с начальным видением, поэтому лучше подстраховаться и иметь запись "а вы говорили вот так"))))
#БА #СА #бизнесаналитик #системныйаналитик #systemanalysis #systemanalyst #bisunessanalys
🔥3
Управление рисками)
Представьте, вы занимаетесь любимым делом, и тут случается риск (негативно влияющее событие). Что же делать?
А делать, и думать - надо было раньше:)
Рисков во всем мире множество:
- естественные (природные условия),
- политические (совсем недавно запретили notion и miro кто ж знал..)
- ... И многие-многие другие)
Как решают данную проблему аналитики?
1 метод - Мозговой штурм.
Соберите зависимых от дела людей, и поговорите с ними.
Не критикуйте, просто генерируйте идеи, записывайте любую глупую идею. Даже глупый риск - может произойти)
2 метод - Фрирайтинг.
Вы один? Не проблема.
Пишите, пишите, пишите. Все что приходит в голову на поставленный вопрос "Какие риски?".
Пишем безостановочно минут 15-20, пока будильник не сработает.
Вы сможете написать тут то, что отмели бы когда думали. Потому что думаем мы на основе полученного опыта, а пишем бессознательно (когда пишем так долго).
3 метод - SWOT анализ.
S - сильные стороны
W - слабые стороны
O - возможности
T - угрозы
Угрозы и есть риски, вдумчиво вы сможете их описать, на основании сильных, слабых сторон и возможностей.
4 метод - Дельфи.
Соберите команду заинтересованных. Здесь будет анонимно.
Составьте опрос - попросите ответить всех на вопросы. Желательно развернуто.
Соберите мнения - сделайте статистические данные, покажите всем.
Составьте опрос повторно, учитывая данные статистики - попросите ответить всех снова, учитывая что они ознакомились с мнением.
Соберите мнения повторно - сделайте статистику, определите риски.
Повторять можно 3 раза, как написано в теории, и промежутки между опросами не должны превышать месяц.
Да, тут долго, но можно сделать и экспресс опросник - главное: Анонимность:)
Плюс вы можете дать обратную связь, и заинтересованные могут поправить вас снова)
Выявили риски.. А что дальше?
А дальше, оцените их.
Действительно ли этот риск такой важный?
Уронили вы в речку мячик, стоит ли из-за этого так расстраиваться? Ведь можно купить новый:)
Вероятность данного события?
Вероятность, что упадет мячик - 50 процентов. Снизить ее можно - отойдя от реки.
Влияние данного события?
Придется идти в магазин, возможность встретить друзей, и т.д..
Обязательно расписываем план, как обойти риск, если вдруг он сильно увесистый.
И, всегда следим за новыми:)
Сейчас вы еще думаете, завтра изменился закон, а послезавтра назначено дело...Следим, бдим, думаем наперед:)
#оценкариска #риск #бизнесаналитик #системныйаналитик #клиент #новыйпроект
Представьте, вы занимаетесь любимым делом, и тут случается риск (негативно влияющее событие). Что же делать?
А делать, и думать - надо было раньше:)
Рисков во всем мире множество:
- естественные (природные условия),
- политические (совсем недавно запретили notion и miro кто ж знал..)
- ... И многие-многие другие)
Как решают данную проблему аналитики?
1 метод - Мозговой штурм.
Соберите зависимых от дела людей, и поговорите с ними.
Не критикуйте, просто генерируйте идеи, записывайте любую глупую идею. Даже глупый риск - может произойти)
2 метод - Фрирайтинг.
Вы один? Не проблема.
Пишите, пишите, пишите. Все что приходит в голову на поставленный вопрос "Какие риски?".
Пишем безостановочно минут 15-20, пока будильник не сработает.
Вы сможете написать тут то, что отмели бы когда думали. Потому что думаем мы на основе полученного опыта, а пишем бессознательно (когда пишем так долго).
3 метод - SWOT анализ.
S - сильные стороны
W - слабые стороны
O - возможности
T - угрозы
Угрозы и есть риски, вдумчиво вы сможете их описать, на основании сильных, слабых сторон и возможностей.
4 метод - Дельфи.
Соберите команду заинтересованных. Здесь будет анонимно.
Составьте опрос - попросите ответить всех на вопросы. Желательно развернуто.
Соберите мнения - сделайте статистические данные, покажите всем.
Составьте опрос повторно, учитывая данные статистики - попросите ответить всех снова, учитывая что они ознакомились с мнением.
Соберите мнения повторно - сделайте статистику, определите риски.
Повторять можно 3 раза, как написано в теории, и промежутки между опросами не должны превышать месяц.
Да, тут долго, но можно сделать и экспресс опросник - главное: Анонимность:)
Плюс вы можете дать обратную связь, и заинтересованные могут поправить вас снова)
Выявили риски.. А что дальше?
А дальше, оцените их.
Действительно ли этот риск такой важный?
Уронили вы в речку мячик, стоит ли из-за этого так расстраиваться? Ведь можно купить новый:)
Вероятность данного события?
Вероятность, что упадет мячик - 50 процентов. Снизить ее можно - отойдя от реки.
Влияние данного события?
Придется идти в магазин, возможность встретить друзей, и т.д..
Обязательно расписываем план, как обойти риск, если вдруг он сильно увесистый.
И, всегда следим за новыми:)
Сейчас вы еще думаете, завтра изменился закон, а послезавтра назначено дело...
#оценкариска #риск #бизнесаналитик #системныйаналитик #клиент #новыйпроект
🔥3
UML
Диаграмма деятельности (Блок схема)
Совсем недавно тут был пост про UML диаграмма последовательности (сиквенсы), вы можете к нему вернуться по ссылочке - Sequence . А сейчас рассмотрим максимально удобную диаграмму ДЛЯ ВСЕХ:)
Как часто вам нужно объяснить в обычной блок схеме что требуется? Очень часто, даже если вы не относитесь к аналитикам или программистам..
Облегчим себе жизнь?)
Нарисуем с вами самую простенькую блок схемку, которую вы сможете исправлять, при необходимости.
Обозначения -
@startuml - начинает программу
@enduml - заканчивает программу
Внутри:
start - для начального кружочка, показываем что начался процесс. (Остановим его stop или end)
Писать текст с помощью
:Текст;
Ромбик - вопрос здесь обозначается с помощью:
if(условие) is (Да) then
:Что произошло;
else (Нет)
:Что произошло;
enfif
Прервать последовательность, без stop/end можно словом kill
Сделать цикл, возврат назад можно если вы в начале цикла введете repeat: Действие, а после на моменте возврата - repeatwhile(Условие для возврата) is(Да) not(Нет)
Режим многопоточности подразумевает распараллеливания действий, можно здесь сделать как И, так и ИЛИ:
fork
: текст
fork again
: текст2
end fork {И}
Создать заметку
note left(right)
endnote
Еще очень много полезных действий для этой диаграммы описано на сайте - Plantuml , ну а мы перейдем к примеру:
@startuml
start
:Хочу постряпать тортик;
if (Хватает ли всех ингредиентов?) is (Нет) then
:Идем в магазин;
stop
else (Да)
:Складываем в тазик;
fork
:Яйца;
fork again
:Мука;
fork again
:Сметана;
fork again
:Сода;
end fork {И}
if(Тесто получается таким как надо?) is (Да) then
note right: Именно муки обычно не хватает
:Все достаточно;
else (Нет)
repeat:Муки;
repeatwhile (Тесто такое как надо?) is(Нет) not(Да)
endif
:Ставим в духовку на 180 градусов ;
stop
@enduml
Вот такой легенький пример показывает, что если бы мы это рисовали - заняло бы минут 20, а написание просто слов - не более 5 минут.
Попробуйте, вам обязательно понравится - https://www.planttext.com :)
#plantuml #activitydiagram #activity #диаграммадеятельности #диаграммаактивностей #sequence #ПишемИРисуем
Диаграмма деятельности (Блок схема)
Совсем недавно тут был пост про UML диаграмма последовательности (сиквенсы), вы можете к нему вернуться по ссылочке - Sequence . А сейчас рассмотрим максимально удобную диаграмму ДЛЯ ВСЕХ:)
Как часто вам нужно объяснить в обычной блок схеме что требуется? Очень часто, даже если вы не относитесь к аналитикам или программистам..
это важно всем, потому что блок схемы нас учили рисовать еще в школе:)Облегчим себе жизнь?)
Нарисуем с вами самую простенькую блок схемку, которую вы сможете исправлять, при необходимости.
Обозначения -
@startuml - начинает программу
@enduml - заканчивает программу
Внутри:
start - для начального кружочка, показываем что начался процесс. (Остановим его stop или end)
Писать текст с помощью
:Текст;
Ромбик - вопрос здесь обозначается с помощью:
if(условие) is (Да) then
:Что произошло;
else (Нет)
:Что произошло;
enfif
Прервать последовательность, без stop/end можно словом kill
Сделать цикл, возврат назад можно если вы в начале цикла введете repeat: Действие, а после на моменте возврата - repeatwhile(Условие для возврата) is(Да) not(Нет)
Режим многопоточности подразумевает распараллеливания действий, можно здесь сделать как И, так и ИЛИ:
fork
: текст
fork again
: текст2
end fork {И}
Создать заметку
note left(right)
endnote
Еще очень много полезных действий для этой диаграммы описано на сайте - Plantuml , ну а мы перейдем к примеру:
@startuml
start
:Хочу постряпать тортик;
if (Хватает ли всех ингредиентов?) is (Нет) then
:Идем в магазин;
stop
else (Да)
:Складываем в тазик;
fork
:Яйца;
fork again
:Мука;
fork again
:Сметана;
fork again
:Сода;
end fork {И}
if(Тесто получается таким как надо?) is (Да) then
note right: Именно муки обычно не хватает
:Все достаточно;
else (Нет)
repeat:Муки;
repeatwhile (Тесто такое как надо?) is(Нет) not(Да)
endif
:Ставим в духовку на 180 градусов ;
stop
@enduml
Вот такой легенький пример показывает, что если бы мы это рисовали - заняло бы минут 20, а написание просто слов - не более 5 минут.
Попробуйте, вам обязательно понравится - https://www.planttext.com :)
#plantuml #activitydiagram #activity #диаграммадеятельности #диаграммаактивностей #sequence #ПишемИРисуем
🔥5👍2
Как писать ТЗ, которое поймут все?
Сегодня хочу поделиться опытом, который спасет вас от бесконечных уточнений, переделок и фразы «Мы думали, вы хотели другое». Речь о том, как писать техническое задание (ТЗ), которое будет понятно и разработчикам, и менеджерам, и, вероятно, первокласснику:)
Почему ТЗ превращается в «китайскую грамоту»?
Частая ошибка аналитиков — писать ТЗ либо слишком абстрактно («Сделайте удобный интерфейс»), либо избыточно технически («Используйте REST API с JWT-токенами»). Итог:
- Разработчики тратят время на угадывание требований.
- Бизнес не видит связи между ТЗ и своими целями.
- Тестировщики не понимают, что проверять.
7 правил для ТЗ, которое поймут все
1. Говорите на языке аудитории
- Для бизнеса: фокусируйтесь на целях и выгодах.
Пример:
❌ «Реализовать интеграцию с 1С через API».
✅ «Сократить время формирования отчетов с 2 часов до 10 минут за счет автоматического обмена данными с 1С».
- Для разработчиков: добавляйте четкие критерии выполнения.
Пример:
❌ «Система должна быть быстрой».
✅ «Время отклика при нагрузке 1000 пользователей — не более 2 сек».
2. Дробите на части
Используйте структуру:
- Цель → Функционал → Детали → Критерии приемки.
Пример для модуля оплаты:
- Цель: Уменьшить число ошибок при ручном вводе реквизитов.
- Функционал: Интеграция с банковским эквайрингом.
- Детали: Поддержка карт Visa/Mastercard, валидация CVC, лог ошибок.
- Критерии приемки: Пользователь вводит карту → система проверяет CVC → при успехе открывает окно подтверждения.
3. Визуализируйте
Слова — это хорошо, но картинки работают лучше. Добавьте:
- Диаграммы процессов (BPMN),
- Мокапы интерфейсов (Figma, Axure),
- Схемы данных (ER-диаграммы).
4. Избегайте «воды»
- Удаляйте все, что не влияет на результат.
- Вместо «Система должна быть удобной» пишите: «Кнопка «Сохранить» расположена в правом верхнем углу, размер — 48×48 px».
5. Предугадывайте вопросы
Пропишите явно:
- Что входит в границы проекта, а что не входит.
- Допущения (например, «Пользователь уже авторизован»).
- Зависимости (например, «Для работы модуля нужен доступ к CRM»).
6. Тестируйте ТЗ на «человеке с улицы»
Дайте прочитать ТЗ коллеге из другого отдела. Если он задает больше 3 уточняющих вопросов — переписывайте.
7. Добавьте глоссарий
Даже очевидные термины могут трактоваться по-разному. Определите:
- «Клиент» = «Пользователь, прошедший регистрацию».
- «Срочный заказ» = «Заказ, оформленный менее чем за 2 часа до выгрузки».
Чек-лист: ТЗ готово, если…
- ✅Каждое требование соотносится с бизнес-целью.
- ✅Нет абстрактных формулировок («удобно», «быстро»).
- ✅Есть критерии, по которым тестировщик проверит функционал.
- ✅Визуальные схемы подтверждают текстовые описания.
- ✅Все участники проекта подписали ТЗ и поняли свою зону ответственности.
🤓 Золотое правило
ТЗ — это не документ, а процесс. Проводите регулярные встречи с командой, чтобы уточнять детали и вносить правки. Помните: даже идеальное ТЗ бесполезно, если его положили в стол до конца проекта.
Удачи! И да пребудет с вами ясность требований 😉
#СистемныйАнализ #системнаяаналитика #бизнесаналитика #БизнесАнализ #техническоезадание #проект #ТЗ #Документация #Agile #BPMN
Сегодня хочу поделиться опытом, который спасет вас от бесконечных уточнений, переделок и фразы «Мы думали, вы хотели другое». Речь о том, как писать техническое задание (ТЗ), которое будет понятно и разработчикам, и менеджерам, и, вероятно, первокласснику:)
Почему ТЗ превращается в «китайскую грамоту»?
Частая ошибка аналитиков — писать ТЗ либо слишком абстрактно («Сделайте удобный интерфейс»), либо избыточно технически («Используйте REST API с JWT-токенами»). Итог:
- Разработчики тратят время на угадывание требований.
- Бизнес не видит связи между ТЗ и своими целями.
- Тестировщики не понимают, что проверять.
7 правил для ТЗ, которое поймут все
1. Говорите на языке аудитории
- Для бизнеса: фокусируйтесь на целях и выгодах.
Пример:
❌ «Реализовать интеграцию с 1С через API».
✅ «Сократить время формирования отчетов с 2 часов до 10 минут за счет автоматического обмена данными с 1С».
- Для разработчиков: добавляйте четкие критерии выполнения.
Пример:
❌ «Система должна быть быстрой».
✅ «Время отклика при нагрузке 1000 пользователей — не более 2 сек».
2. Дробите на части
Используйте структуру:
- Цель → Функционал → Детали → Критерии приемки.
Пример для модуля оплаты:
- Цель: Уменьшить число ошибок при ручном вводе реквизитов.
- Функционал: Интеграция с банковским эквайрингом.
- Детали: Поддержка карт Visa/Mastercard, валидация CVC, лог ошибок.
- Критерии приемки: Пользователь вводит карту → система проверяет CVC → при успехе открывает окно подтверждения.
3. Визуализируйте
Слова — это хорошо, но картинки работают лучше. Добавьте:
- Диаграммы процессов (BPMN),
- Мокапы интерфейсов (Figma, Axure),
- Схемы данных (ER-диаграммы).
4. Избегайте «воды»
- Удаляйте все, что не влияет на результат.
- Вместо «Система должна быть удобной» пишите: «Кнопка «Сохранить» расположена в правом верхнем углу, размер — 48×48 px».
5. Предугадывайте вопросы
Пропишите явно:
- Что входит в границы проекта, а что не входит.
- Допущения (например, «Пользователь уже авторизован»).
- Зависимости (например, «Для работы модуля нужен доступ к CRM»).
6. Тестируйте ТЗ на «человеке с улицы»
Дайте прочитать ТЗ коллеге из другого отдела. Если он задает больше 3 уточняющих вопросов — переписывайте.
7. Добавьте глоссарий
Даже очевидные термины могут трактоваться по-разному. Определите:
- «Клиент» = «Пользователь, прошедший регистрацию».
- «Срочный заказ» = «Заказ, оформленный менее чем за 2 часа до выгрузки».
Чек-лист: ТЗ готово, если…
- ✅Каждое требование соотносится с бизнес-целью.
- ✅Нет абстрактных формулировок («удобно», «быстро»).
- ✅Есть критерии, по которым тестировщик проверит функционал.
- ✅Визуальные схемы подтверждают текстовые описания.
- ✅Все участники проекта подписали ТЗ и поняли свою зону ответственности.
🤓 Золотое правило
ТЗ — это не документ, а процесс. Проводите регулярные встречи с командой, чтобы уточнять детали и вносить правки. Помните: даже идеальное ТЗ бесполезно, если его положили в стол до конца проекта.
Удачи! И да пребудет с вами ясность требований 😉
#СистемныйАнализ #системнаяаналитика #бизнесаналитика #БизнесАнализ #техническоезадание #проект #ТЗ #Документация #Agile #BPMN
❤2🔥1
Теория API
Существует несколько архитектурных стилей API:
🛠 REST API
🛠GraphQL
🛠SOAP API
🛠gRPC API
Давай разберём главные теоретические принципы REST API?
1. API — это не только «техническая штука», этофилософия
Представь, что мир — это куча островов. Каждый остров — это система (банк, CRM, мобильное приложение). API — это мосты между ними.
Без API острова общаются так:
- «Эй, банк! Кидай мне данные своих клиентов в Excel по почте!»
- «Ок, но это займёт три дня, и файл сломается при открытии» 💥.
С API общение выглядит так:
- «Банк, дай мне баланс клиента 123» -> «Держи: {"balance": 5000}» (за 0.5 сек).
Вывод: API нужен, чтобы системы говорили на одном языке быстро и без костылей.
2. Главные принципы REST API (те самые, которые все любят)
🧩Stateless (без сохранения состояния)
Сервер не помнит, кто ты. Каждый запрос — независим.
Это как общение с роботом:
- Ты: «Дай мне заказ №1» -> Робот: «Вот заказ»
- Ты: «Теперь дай заказ №2» -> Робот: «А ты кто? Назови токен!»
👉 Фишка: Нужно каждый раз отправлять данные для аутентификации (токен, ключ).
🧩 Ресурсы и URI (как «адреса» данных)
Каждая сущность (пользователь, заказ) — это ресурс с уникальным URL.
Примеры:
- GET /users/123 -> Получить пользователя с ID 123.
- DELETE /orders/456 -> Удалить заказ 456.
Почему это удобно? Потому что это единый стандарт. Все REST API работают похоже.
🧩 HTTP-методы = действия
GET - Получение информации - Идемпотентный (т.е. вызвав несколько раз подряд - получим тот же результат) - Повторные GET запросы не изменят состояние сервера - Код успеха: 200
POST - Создание информации - Неидемпотентен (Каждый следующий запрос будет создавать новый ресурс) - Код успеха: 201
PUT - Полное обновление информации - Идемпотентен (один и тот же результат) - Код успеха: 200
PATCH - Частичное обновление информации - Неидемпотентен (Т.к. в него можно вставить инструкцию добавления элемента , а вот PUT - перезаписал бы целиком) - Код успеха: 200
DELETE - Удаление информации - Идемпотентен (многократное удаление приводит все к тому же единственному удалению) - Код успеха: 204
3. Безопасность: Как системы доверяют друг другу
Три уровня защиты API:
Аутентификация (кто ты?) 🚪
- API-ключи (простые, но небезопасные)
- OAuth 2.0 (делегирование прав)
- JWT (токены с цифровой подписью)
Авторизация (что тебе можно?) 🪞
- RBAC (ролевая модель)
- Scope в OAuth
Валидация (корректны ли данные?) 🪭
- Проверка типов
- Ограничения значений
4. Форматы обмена: JSON vs XML
JSON (Современный стандарт)
{
"transaction": {
"id": "1014",
"amount": 100.50,
"currency": "RUB"
}
}
Преимущества:
- Компактность
- Быстрый парсинг
- Поддержка всеми языками
XML (Легаси-системы)
<Transaction>
<ID>1014</ID>
<Amount>100.50</Amount>
<Currency>RUB</Currency>
</Transaction>
Где встречается:
- Банковские системы
- Государственные порталы
- Устаревшие ERP
5. Практика для аналитиков: Что проверять?
Документация API:
- Swagger/OpenAPI-спецификации
- Примеры запросов
- Коды ошибок
Ограничения:
- Rate limiting (ограничение запросов)o
- Квоты использования
- Размеры payload
Сценарии ошибок:
- Таймауты соединения
- Невалидные данные
- Отзыв токенов
Подводим итоги..
Ситуация: Заказчик говорит: «Наш сайт должен показывать курсы валют».
Плохой аналитик:
— «Нужно парсить сайт ЦБ РФ каждые 10 минут» (костыль).
Хороший аналитик:
— «Используем официальное API ЦБ: GET https://www.cbr-xml-daily.ru/daily_json.js. Данные обновляются раз в день, ключ не нужен».
Разница: Второй вариант надёжнее, быстрее и дешевле в разработке.
#СистемныйАнализ #системнаяаналитика #бизнесаналитика #БизнесАнализ #техническоезадание #RESTAPI #API #REST #Теория
Существует несколько архитектурных стилей API:
🛠 REST API
🛠GraphQL
🛠SOAP API
🛠gRPC API
Давай разберём главные теоретические принципы REST API?
1. API — это не только «техническая штука», это
Представь, что мир — это куча островов. Каждый остров — это система (банк, CRM, мобильное приложение). API — это мосты между ними.
Без API острова общаются так:
- «Эй, банк! Кидай мне данные своих клиентов в Excel по почте!»
- «Ок, но это займёт три дня, и файл сломается при открытии» 💥.
С API общение выглядит так:
- «Банк, дай мне баланс клиента 123» -> «Держи: {"balance": 5000}» (за 0.5 сек).
Вывод: API нужен, чтобы системы говорили на одном языке быстро и без костылей.
2. Главные принципы REST API (те самые, которые все любят)
🧩Stateless (без сохранения состояния)
Сервер не помнит, кто ты. Каждый запрос — независим.
Это как общение с роботом:
- Ты: «Дай мне заказ №1» -> Робот: «Вот заказ»
- Ты: «Теперь дай заказ №2» -> Робот: «А ты кто? Назови токен!»
👉 Фишка: Нужно каждый раз отправлять данные для аутентификации (токен, ключ).
🧩 Ресурсы и URI (как «адреса» данных)
Каждая сущность (пользователь, заказ) — это ресурс с уникальным URL.
Примеры:
- GET /users/123 -> Получить пользователя с ID 123.
- DELETE /orders/456 -> Удалить заказ 456.
Почему это удобно? Потому что это единый стандарт. Все REST API работают похоже.
🧩 HTTP-методы = действия
GET - Получение информации - Идемпотентный (т.е. вызвав несколько раз подряд - получим тот же результат) - Повторные GET запросы не изменят состояние сервера - Код успеха: 200
POST - Создание информации - Неидемпотентен (Каждый следующий запрос будет создавать новый ресурс) - Код успеха: 201
PUT - Полное обновление информации - Идемпотентен (один и тот же результат) - Код успеха: 200
PATCH - Частичное обновление информации - Неидемпотентен (Т.к. в него можно вставить инструкцию добавления элемента , а вот PUT - перезаписал бы целиком) - Код успеха: 200
DELETE - Удаление информации - Идемпотентен (многократное удаление приводит все к тому же единственному удалению) - Код успеха: 204
3. Безопасность: Как системы доверяют друг другу
Три уровня защиты API:
Аутентификация (кто ты?) 🚪
- API-ключи (простые, но небезопасные)
- OAuth 2.0 (делегирование прав)
- JWT (токены с цифровой подписью)
Авторизация (что тебе можно?) 🪞
- RBAC (ролевая модель)
- Scope в OAuth
Валидация (корректны ли данные?) 🪭
- Проверка типов
- Ограничения значений
4. Форматы обмена: JSON vs XML
JSON (Современный стандарт)
{
"transaction": {
"id": "1014",
"amount": 100.50,
"currency": "RUB"
}
}
Преимущества:
- Компактность
- Быстрый парсинг
- Поддержка всеми языками
XML (Легаси-системы)
<Transaction>
<ID>1014</ID>
<Amount>100.50</Amount>
<Currency>RUB</Currency>
</Transaction>
Где встречается:
- Банковские системы
- Государственные порталы
- Устаревшие ERP
5. Практика для аналитиков: Что проверять?
Документация API:
- Swagger/OpenAPI-спецификации
- Примеры запросов
- Коды ошибок
Ограничения:
- Rate limiting (ограничение запросов)o
- Квоты использования
- Размеры payload
Сценарии ошибок:
- Таймауты соединения
- Невалидные данные
- Отзыв токенов
Подводим итоги..
Ситуация: Заказчик говорит: «Наш сайт должен показывать курсы валют».
Плохой аналитик:
— «Нужно парсить сайт ЦБ РФ каждые 10 минут» (костыль).
Хороший аналитик:
— «Используем официальное API ЦБ: GET https://www.cbr-xml-daily.ru/daily_json.js. Данные обновляются раз в день, ключ не нужен».
Разница: Второй вариант надёжнее, быстрее и дешевле в разработке.
#СистемныйАнализ #системнаяаналитика #бизнесаналитика #БизнесАнализ #техническоезадание #RESTAPI #API #REST #Теория
1❤4👍2
100 подписчиков и мысли об эффективном системном аналитике
Сегодня у меня маленький личный праздник — этот блог преодолел рубеж в 100 подписчиков! Искренне рада этому первому, такому важному результату! Спасибо каждому из вас, кто читает, думает вместе со мной и поддерживает. Это вдохновляет делиться самым ценным.
И в честь этого круглого числа хочу поделиться мыслями на тему, что делает системного аналитика по-настоящему эффективным?
1. Детективное любопытство: копать до сути
Хороший аналитик фиксирует «что нужно». Эффективный - выясняет «зачем» это нужно.
Как проявляется: Настойчиво задает уточняющие вопросы, пока не найдет корневую проблему бизнеса, а не ее симптом.
Пример:
Пользователи тратят 3 часа в день на ручное копирование данных из системы в отчет. Им нужна автоматизированная выгрузка данных за выбранный период в один клик. Цель - сэкономить 15 человеко-часов в неделю.
А не просто - нам нужно скачивание.
2. Системное мышление: видеть связи, а не разрозненные части
Хороший аналитик описывает функциональность модуля. Эффективный - держит в голове всю экосистему.
Как проявляется: Прежде чем предложить решение, анализирует его влияние на другие компоненты, смежные команды и будущее развитие продукта.
Пример:
Прежде чем внедрять новую доработку, мы должны проверить, как она увеличит нагрузку на базу данных и не потребуется ли изменения в других модулях
3. Упрямство принципиалиста: отстаивать целостность решения
Хороший аналитик соглашается на правки. Эффективный - аргументированно говорит «нет» (или предлагает сильную альтернативу), если изменение вредит архитектуре или бизнес-целям.
Как проявляется: Не боится сложных разговоров, защищает выстроенную логику решения данными и фактами, а не мнениями.
Пример:
Я понимаю желание добавить эту доработку, но это нарушит то и то. Давайте рассмотрим альтернативу или откажемся вовсе от этой доработки.
4. Коммуникация как искусство: быть «клеем» команды
Хороший аналитик передает информацию. Эффективный - создает общее понимание.
Как проявляется: Говорит на языках бизнеса, разработки и дизайна, предвидит недопонимание и заранее устраняет его.
Пример:
Проводит воркшоп, где на доске рисует схему процесса, которую одновременно понимают и продукт-менеджер, и ведущий разработчик.
Чек-лист: Проверьте, на пути ли вы к эффективности?
- Вы можете за 5 минут набросать схему того, как новая функция влияет на другие модули?
- У вас бывали случаи, когда вы отстояли свое решение перед стейкхолдером, и это спасло проект от проблем?
- Вы знаете бизнес-цель каждого требования, а не просто его текст?
- После ваших пояснений исчезают споры между разработкой и бизнесом?
Резюмируем
Эффективный аналитик - это не должность, а роль. Это стратег, который видит дальше текущего спринта, архитектор, который проектирует устойчивые системы, и лидер мнений, который строит мосты понимания в команде.
А что для вас - главный признак эффективного аналитика? Делитесь в комментариях!
#СистемныйАналитик #SystemAnalyst #БизнесАнализ #БизнесАналитик #КарьераВИТ #Аналитика #РазработкаПО #Лидерство #100подписчиков
Сегодня у меня маленький личный праздник — этот блог преодолел рубеж в 100 подписчиков! Искренне рада этому первому, такому важному результату! Спасибо каждому из вас, кто читает, думает вместе со мной и поддерживает. Это вдохновляет делиться самым ценным.
И в честь этого круглого числа хочу поделиться мыслями на тему, что делает системного аналитика по-настоящему эффективным?
1. Детективное любопытство: копать до сути
Хороший аналитик фиксирует «что нужно». Эффективный - выясняет «зачем» это нужно.
Как проявляется: Настойчиво задает уточняющие вопросы, пока не найдет корневую проблему бизнеса, а не ее симптом.
Пример:
Пользователи тратят 3 часа в день на ручное копирование данных из системы в отчет. Им нужна автоматизированная выгрузка данных за выбранный период в один клик. Цель - сэкономить 15 человеко-часов в неделю.
А не просто - нам нужно скачивание.
2. Системное мышление: видеть связи, а не разрозненные части
Хороший аналитик описывает функциональность модуля. Эффективный - держит в голове всю экосистему.
Как проявляется: Прежде чем предложить решение, анализирует его влияние на другие компоненты, смежные команды и будущее развитие продукта.
Пример:
Прежде чем внедрять новую доработку, мы должны проверить, как она увеличит нагрузку на базу данных и не потребуется ли изменения в других модулях
3. Упрямство принципиалиста: отстаивать целостность решения
Хороший аналитик соглашается на правки. Эффективный - аргументированно говорит «нет» (или предлагает сильную альтернативу), если изменение вредит архитектуре или бизнес-целям.
Как проявляется: Не боится сложных разговоров, защищает выстроенную логику решения данными и фактами, а не мнениями.
Пример:
Я понимаю желание добавить эту доработку, но это нарушит то и то. Давайте рассмотрим альтернативу или откажемся вовсе от этой доработки.
4. Коммуникация как искусство: быть «клеем» команды
Хороший аналитик передает информацию. Эффективный - создает общее понимание.
Как проявляется: Говорит на языках бизнеса, разработки и дизайна, предвидит недопонимание и заранее устраняет его.
Пример:
Проводит воркшоп, где на доске рисует схему процесса, которую одновременно понимают и продукт-менеджер, и ведущий разработчик.
Чек-лист: Проверьте, на пути ли вы к эффективности?
- Вы можете за 5 минут набросать схему того, как новая функция влияет на другие модули?
- У вас бывали случаи, когда вы отстояли свое решение перед стейкхолдером, и это спасло проект от проблем?
- Вы знаете бизнес-цель каждого требования, а не просто его текст?
- После ваших пояснений исчезают споры между разработкой и бизнесом?
Резюмируем
Эффективный аналитик - это не должность, а роль. Это стратег, который видит дальше текущего спринта, архитектор, который проектирует устойчивые системы, и лидер мнений, который строит мосты понимания в команде.
А что для вас - главный признак эффективного аналитика? Делитесь в комментариях!
#СистемныйАналитик #SystemAnalyst #БизнесАнализ #БизнесАналитик #КарьераВИТ #Аналитика #РазработкаПО #Лидерство #100подписчиков
7❤4🔥1