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

https://scrumtrek.ru/blog/product-management/5615/behavior-driven-development/

​​Отличия SQL и NoSQL баз данных

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

➕ Плюсы SQL БД

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

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

✔️ Стандартизированный язык для манипуляции с данными - SQL - вне зависимости от того какая СУБД перед вами MySQL MS SQL Oracle или PostgreSQL - язык плюс-минус будет одинаковым для всех типов с незначительными синтаксическими отличиями.

✔️ Простота внедрения - решения на базе SQL внедрять проще с точки зрения начальных затрат и последующей окупаемости.

➖ Теперь немного о минусах

➡️ Сложность настройки и сопровождения при больших объемах данных.
➡️ Негибкость - внесение изменений в структуру требуют большого времени и ресурсов.
➡️ Горизонтальная масштабируемость - сложность распределить таблицы с данными по разными серверам
➡️ Дорогое решение если говорить о возможности приобретения достаточно мощного сервера или серверов под большую нагрузку или размер базы.

➕ Плюсы NoSQL БД

✅ Возможность хранения больших неструктурированных данных
✅ Горизонтальное масштабирование - нет необходимости покупать более дорогой сервер при увеличении нагрузки на базу или ее роста.
✅ Легкость внесения изменений в существующую структуру хранения. Нет ограничений на типы данных и строгой привязки к схемам
✅ Простая репликация - это означает что можно копировать измененные данные на другие сервера.
✅ Шардинг - то есть информация в БД будет разделена по разным узлам сети. При этом каждый узел будет отвечать только за свой набор данных и манипуляции с ними
Скорость и простота разработки

➖ Немного о минусах

▶️ Привязка конкретной NoSQL СУБД к определенному синтаксису для выполнения манипуляций с данными
▶️ Сложность проектирования моделей данных и внедрения технологии
▶️ Не очень хорошая предсказуемость с точки зрения возникновения узких мест в спроектированных системах
▶️ Обеспечение достаточной целостности данных - в отличие от реляционных БД имеется риск потери данных или их плохая консистентность

Нет волшебной таблетки по использованию SQL или NoSQL парадигмы в конкретной ситуации. Важно отталкиваться от задачи.

24.02 (четверг), в 17.00 (по Минску, GMT+3) присоединяйтесь к свободному разговору в формате live с экспертом по регулярному менеджменту и профессиональной эксплуатации персонала, Александром Фридманом.

Будет полезно для:
- PM, DM и BA
- руководителей высокотехнологичного бизнеса
- и просто любопытствующих теоретиков.

Мероприятие бесплатное, но число мест ограничено, так что не забудьте зарегистрироваться!
Если хотите задать Александру Фридману вопрос, это можно сделать по ссылке: https://forms.gle/oeF4FWuGhUpAgGQi9

Чтобы не пропустить ссылку на саму конференцию, подписывайтесь на тг-канал Andersen People live - все важные новости и анонсы там: https://news.1rj.ru/str/andersen_people

Статья для тех, кто ищет для себя идеальную технику тайм-менеджмента.
https://habr.com/ru/company/click/blog/651393/

​​Три главных боли аналитика (и не только).

Статья от системного аналитика Кристины Горбуновой о том, с какими трудностями может столкнуться аналитик во время своей работы и как с этим справиться.


👉🏻 Боль №1.
Оценки сроков проекта сделана до тебя, а соблюдать их нужно тебе
Сразу по самому больному, да)

☝🏻 Почему так бывает:

а) Оценку делали не по хорошим формулам (где к первой оценке прибавляют 40%), а по плохим формулам (делят на два). То есть, сроки спустили сверху.
б) Сюр или так еще бывает? Оценку делал человек, который считает, что приложение для банка можно сделать за два месяца. И добавить кнопочку - это просто нарисовать кнопочку) Никакого тебе фронта, API, бэка, очередей…

🔥 Что можно сделать:

📎 Рассказать, что именно скрывается за работой аналитика : продумать и прописать подробную логику, учесть все связи требований, архитектуру и масштабирование проекта, поговорить с кучей людей и синтезировать их требования;
📎 Взять важную задачу и провести по ней нормальную оценку. Экстраполировать на остальные. Аргументировать. Найти авторитетную поддержку своим срокам;
📎 После первой итерации, если/когда сроки провалены, сделать картинку “Ожидание VS Реальность”. Предложить другую оценку, обосновать;
📎 Урезать требования. Тут важно понять, какие требования высечены в камне, а какие можно подвинуть. Как понять? По реакции заказчика, когда начинаешь их резать)
📎 Увеличивать свою эффективность;
📎 Расширять команду;
📎 Перерабатывать;
📎 Увольняться/менять проект (я серьезно, но пункт последний в списке не зря).

👉🏻 Боль №2.
Погружение в новый проект.

Горы документации, часто неактуальной; куча людей, из которых надо вытащить то, что не написано в документации; тестирование API, селекты в БД, чтение кода….Все для того, чтобы разобраться)

🔥 Что можно сделать:

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

👉🏻 Боль №3.
Изменение требований.

☝🏻 Почему так бывает, мы все знаем. Бизнес живой, софт живой, всё бежит и меняется.

🔥 Что делаем:

Чем проще проект, тем больше всего можно держать в голове. Несколько ключевых людей проекта знают, что с чем связано и почему. Но проекты всегда растут, и поэтому этот способ несет приличные риски. И еще, голова нужна не для хранения информации, а для того, чтобы ею думать)
Разберем два понятия - связанность (трассировка) и изменение требований.
📎 Трассировка требований - знать, а лучше задокументировать, как связаны требования. Мы должны “это” отобразить на интерфейсе клиенту, а значит “это” надо откуда-то взять. И дальше по цепочке - откуда берем, как обрабатываем, куда складываем.
📎 Изменение требований - когда меняется любой элемент в этой цепочке.
Нужно создать свою систему отслеживания связей требований, и тогда при любом изменении будет видно, что оно за собой потянет.
Эта тема заслуживает отдельной большой статьи. 📍Как минимум, связь можно отслеживать в созданной таблице. 📍Как максимум - есть инструменты IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.

Рекомендация от автора нашей последней статьи: статья от Татьяны Крутовой, как быстро погрузиться в проект с "историей".
http://orderskills.ru/project-with-story/

Интересная статья для системных аналитиков👉🏻

https://habr.com/ru/company/maxilect/blog/553408/

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

https://habr.com/ru/company/surfstudio/blog/655077/

Подробная статья на английском языке, как пройти сертификацию PSPO успешно, от Кристины Юнчиц, бизнес аналитика в компании Andersen.
👉🏻 В статье приведены лучшие практики и методы подготовки, а также масса полезных ссылок.
❗️Все, что нужно, чтобы сдать на PSPO с первого раза!

https://telegra.ph/How-to-pass-PSPO-successfully-04-08

Полезная статья об impact mapping 👉🏻

https://habr.com/ru/post/652577/

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

https://habr.com/ru/post/656587/

Статья о том, как добиться 100% требований пользовательского интерфейса.

https://www.adaptiveus.com/blog/how-to-elicit-100-ui-requirements

​​Замечательная работа по документированию API. Около 900 страниц теории + практические задания.

Оригинал на английском языке 👉🏻 https://idratherbewriting.com/learnapidoc/
Перевод на русский язык (но за качество и полноту изложения не ручаемся) 👉🏻 https://starkovden.github.io/index.html

​​Что такое API и какую функцию выполняет?

В новой стать от бизнес-аналитика Екатерины Авдевич узнаем, что такое API и зачем это нужно

📍API — (Application Programming Interface) это инструмент, который позволяет программам\приложениям\сайтам обмениваться между собой необходимой им информацией. API является промежуточным слоем между приложением и web сервисом, который помогает обрабатывать данные.

Как работает API?

📌Приложение клиента посылает запрос API для получения определенной информации от web сервиса
📌Если запрос в web сервис оказался валидным, тогда API вызывает внешний сервис (web сервис)
📌Внешний сервис отправляет API запрашиваемые данные
📌API осуществляет передачу данных приложению клиента.

Какие существуют типы API?

В настоящее время большинство интерфейсов прикладного программирования представляют собой web-API, которые предоставляют данные и функции приложения через Интернет.
Существует четыре основных типа web-API:
🔺 Открытые API — это интерфейсы программирования приложений с открытым исходным кодом, к которым вы можете получить доступ по протоколу HTTP. Также известные как общедоступные API, они имеют определенные конечные точки API и форматы запросов и ответов.
🔺API-интерфейсы партнеров — это интерфейсы прикладного программирования, предоставляемые стратегическим деловым партнерам или ими. Как правило, разработчики могут получить доступ к этим API в режиме самообслуживания через общедоступный портал разработчиков API. Тем не менее им необходимо будет пройти процесс адаптации и получить учетные данные для входа в систему для доступа к партнерским API.
🔺Внутренние API — это интерфейсы программного обеспечения, которые остаются скрытыми от внешних пользователей. Эти частные API недоступны для пользователей за пределами компании и вместо этого предназначены для повышения производительности и взаимодействия между различными внутренними группами разработчиков.
🔺Составные API-интерфейсы объединяют несколько API-интерфейсов данных или служб. Эти сервисы позволяют разработчикам получать доступ к нескольким конечным точкам за один вызов. Составные API полезны в архитектуре микросервисов, где для выполнения одной задачи может потребоваться информация из нескольких источников.

Почему разработчикам интересен API?

☝️API упрощает и ускоряет создание новых продуктов. Разработчикам не приходится каждый раз изобретать велосипед. Можно взять API Google календаря и подключить к своей внутренней CRM системе удобный интерфейс планирования рабочего времени сотрудников.
Также использование API максимально выгодно для клиента, поскольку это снижает стоимость продукта
Хороший и проработанный программный интерфейс всегда увеличивает безопасность разработки.

Почему бизнесу нужен API?

📎Помогает в интеграции между клиентскими и партнерскими системами
📎Помогает проводить транзакции
📎Помогает увеличить безопасность процессов
📎Помогает развивать собственные софты

​​С днём бизнес аналитика!
Профессионального развития и самореализации, а также не забываем жить во всю мощь!

​​Продолжаем небольшую серию статей о системном анализе от бизнес-аналитика Екатерины Авдевич.
Сегодняшняя тема "Что такое протокол передачи данных и какими они бывают?"

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

☝️Протокол передачи данных - это соглашение, в котором определяются правила обмена данными между разными ПО.

Как можно классифицировать протоколы?

📎 Протоколы низшего уровня - к ним относятся физические, канальные, сетевые и транспортные протоколы
📎Протоколы верхнего уровня - прикладные, сеансовые и протоколы представления
📎Протоколы промежуточного уровня - это коммуникационные и протоколы аутентификации

Какие бывают протоколы?

Базовой парой всех имеющихся протоколов являются протоколы TCP/IP - протокол управления передачей/Протокол Интернета
TCP/IP состоит из двух протоколов:
➖Протокол верхнего уровня - TCP - отвечает за правильность формирования сообщений в пакеты
➖Протокол нижнего уровня - IP - отвечает за правильность доставки сообщений по указанному адресу. Иначе, его называют протоколом маршрутизации. Именно благодаря IP компьютеры в сети имеют свой индивидуальный адрес. По этому адресу и происходит передача данных, по другому их называют URL-адреса

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

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

DNS - протокол, без которого не сможет работать система доменных имён. Протокол дает возможность клиентским компьютерам запрашивать у DNS-сервера IP-адрес какого-нибудь сайта, плюс он помогает осуществлять обмен БД между серверами DNS. В работе системы также используются протоколы TCP и UDP.

POP3 - протокол, который применяется для соединения с почтовым сервисом. Протокол POP обрабатывает данные на получение почты от клиентских программ.

SMTP - протокол, который устанавливает определенные правила для отправки почты.

настало время немного снизить градус рабочего напряжения 😁
#BAmemeRU

​​Завершаем небольшую серию статей о системном анализе от бизнес-аналитика Екатерины Авдевич.

Тонкий и толстый клиенты. Что это?

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

Что такое тонкий клиент?

Тонкий клиент - это такой вид клиента который способен все запросы пользователя по обработке данных переносить на сервер.

Плюсы тонкого клиента:
📎Доступ к информации становится безопаснее, т.к. информация хранится на стороннем сервисе
📎Обслуживание ПО становится минимальным, в связи с этим сокращаются трудозатраты
📎Минимальный уровень появления неисправности
📎Низкие технические требования к аппаратуре

Минусы тонкого клиента:
📎При возникновении сбоя - “поломаются” все подключенные к системе пользователи
📎Невозможно работать без сети
📎Может снижаться объем обработки большого массива данных

Что такое толстый клиент?

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

Плюсы толстого клиента:
📎Высокая функциональность
📎Работать одновременно могут несколько пользователей
📎Возможность работы без сети
📎Оперативное реагирование системы
📎Нет зависимости от сторонних серверов

Минусы толстого клиента:
📎Обслуживание ПО становиться трудозатратным
📎Необходимо постоянное индивидуальное обновление программного обеспечения
📎Массивные объемы дистрибутивов
📎Программное обеспечение зависит от платформы, на которой были созданы клиенты

​​Good day, dear readers! The administration of the channel writes to you.

We started publishing exciting news and articles more than a year ago, and during this time we have gathered more than 1,700 business and system analysts interested in knowledge of our position! Our community has organized many online and offline meetups during this time, and we have invited the best speakers for you. And sometimes we just published thematic humor so you could relax a little.

We will continue to grow. And since July we will add a lot of new things:

- switch to English, for more audience coverage;
- we will add comments for all our publications, for live discussions on topics;
- we will hold new meetups;
- and we will add more authors' articles.

Thanks,
Stay tuned💛