А как вы думаете, нужно ли бизнес аналитику знать языки программирования?
Anonymous Poll
4%
Да, нужны глубокие знания одного/двух языков
44%
Да, но нужны только поверхностные знания
24%
Нет, это не нужно, но я бы все равно хотел(а) бы уметь кодить
11%
Нет, считаю это совершенно лишним
17%
Хочу просто посмотреть ответы
Интересная статья, как понять и объяснить, что такое RACI матрица простыми словами.☝🏻
https://habr.com/ru/company/timeweb/blog/597281/
https://habr.com/ru/company/timeweb/blog/597281/
Хабр
«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица
Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала...
❗️ Дорогие друзья!
👉🏻 Andersen запускает новый формат встреч - BA Talks!
11 февраля приглашаем в Ивент-пространство "30th Floor" на офлайн-мероприятие, где в уютной и неформальной обстановке мы вместе обсудим актуальные для бизнес-аналитиков темы, послушаем выступления классных спикеров и поделимся своими инсайтами!
Вас ожидают:
📌 доклад от ведущего аналитика и эксперта в домене Healthcare Виталия Бирченко о подготовке к международным конференциям;
📌 доклад от руководителя департамента BA и SA Марии Боярко о том, каким хотят видеть бизнес-аналитика заказчики;
📌 обсуждение тем и нетворкинг с участниками;
📌 интерактив и подарки от Andersen;
📌 угощения и напитки.
🔥 Гарантируем прекрасное настроение и отличную мотивацию для профессионального развития!
📅 Когда: 11 февраля 19:00
🏬 Где: Ивент-пространство "30th Floor" г.Минск, пр-т Победителей 7а, 30-й этаж
✏️ Регистрация тут: https://forms.gle/1BNsLABKD9ZQuQAR6
Советуем поторопиться, ведь количество мест ограничено!
До встречи на BA Talks в Andersen!
👉🏻 Andersen запускает новый формат встреч - BA Talks!
11 февраля приглашаем в Ивент-пространство "30th Floor" на офлайн-мероприятие, где в уютной и неформальной обстановке мы вместе обсудим актуальные для бизнес-аналитиков темы, послушаем выступления классных спикеров и поделимся своими инсайтами!
Вас ожидают:
📌 доклад от ведущего аналитика и эксперта в домене Healthcare Виталия Бирченко о подготовке к международным конференциям;
📌 доклад от руководителя департамента BA и SA Марии Боярко о том, каким хотят видеть бизнес-аналитика заказчики;
📌 обсуждение тем и нетворкинг с участниками;
📌 интерактив и подарки от Andersen;
📌 угощения и напитки.
🔥 Гарантируем прекрасное настроение и отличную мотивацию для профессионального развития!
📅 Когда: 11 февраля 19:00
🏬 Где: Ивент-пространство "30th Floor" г.Минск, пр-т Победителей 7а, 30-й этаж
✏️ Регистрация тут: https://forms.gle/1BNsLABKD9ZQuQAR6
Советуем поторопиться, ведь количество мест ограничено!
До встречи на BA Talks в Andersen!
👍1
Статья размышление от проблемах быстрорастущих компаний от бизнес аналитика Дмитрия Агафонцева.
https://telegra.ph/Problemy-bystrorastushchih-kompanij-na-kotorye-chasto-ne-obrashchayut-vnimaniya-02-02
https://telegra.ph/Problemy-bystrorastushchih-kompanij-na-kotorye-chasto-ne-obrashchayut-vnimaniya-02-02
Telegraph
Проблемы быстрорастущих компаний, на которые часто не обращают внимания.
Небольшое исследование-наблюдение из жизни компаний и вопросов эффективности персонала. Дисклеймер: при написании данной статьи автор не задавался целью оскорбить какую-либо организацию и публично уличить в бездействии или умышленном устроении описанных ниже…
Что такое ETL?
Давайте разберёмся с самого начала. ETL — сокращение от Extract, Transform, Load.
➡️ E – extract = добыча данных, извлечение их из какого — либо источника
➡️ T – transform = преобразование данных. После того как прошёл этап и извлечения данных нам нужно их обработать, преобразовать в формат, который нас устроит.
➡️ L load = загрузка данных в целевое хранилище.
А теперь по порядку.
Возникает вопрос - для чего же существует процесс ETL? Какие цели он преследует?
Представьте компанию, которая содержит в себе каталог различных продуктов от разных Поставщиков. Для размещения этих продуктов в каталоге нужно получать различную информацию о них от разных Поставщиков: цена, остатки на складах и т.д. Для такого процесса характерно большое количество интеграций, каждая из которых характеризуется наличием «cобственного» процесса ETL.
Простым языком, что же происходит? Данные извлекаются, затем проходят процесс трансформации и поскольку форматы данных, которые хранятся у различных Поставщиков разные, крайне важно привести данные к некоему унифицированному виду, модели поведения, и, наконец, загрузить в БД.
Также ETL процессы должны отвечать некоторым требованиям бизнеса как то:
1️⃣ Решение по ETL процессам должно быть стандартным = максимально распространённым, чтобы облегчить работу с ним.
2️⃣ Быстрое внедрение новых интеграций. Т.е. изменение формата передачи новых данных не должно приводить к длительным процессам разработки, внедрения и т.д.
3️⃣ Адекватная стоимость. Стоимость разработки, внедрения не должна быть высокой = должна соответствовать формуле «один раз настроили — подняли — внедрили».
Какие технические вопросы могут возникнуть при внедрении процессов ETL?
✏️ Необходимость отслеживать состояние интеграций. Какие процессы сейчас работают, с какой скоростью и т.д.
✏️ Существуют движки для внедрения ETL, но они требуют доработок (админка, роли, логирование…)
✏️ Для построения ETL удобно использовать DAG – directed acyclic graph, который позволяет построить «дерево», у которого много разных ветвлений. Но этот движок требует много дополнительного программного обеспечения.
✏️ Как следствие возникает потребность в привлечении отдельного специалиста, который бы разобрался бы в том как движок работает и устроен, специалиста, который написал бы кучу кода для имплементации бизнес — логики, что является достаточно долгим и дорогостоящим процессом и иногда приводит к переписыванию значительной части кода.
✏️ Для построения ETL процессов часто используются отличные от используемых в компаниях языки программирования, соответственно, уходит время на то, чтобы разобраться с ними.
☝🏻 Таким образом, ETL процессы несут в себе большую значимость и ценность, но стоит хорошо подготовиться перед тем как начать работать с ними.
Давайте разберёмся с самого начала. ETL — сокращение от Extract, Transform, Load.
➡️ E – extract = добыча данных, извлечение их из какого — либо источника
➡️ T – transform = преобразование данных. После того как прошёл этап и извлечения данных нам нужно их обработать, преобразовать в формат, который нас устроит.
➡️ L load = загрузка данных в целевое хранилище.
А теперь по порядку.
Возникает вопрос - для чего же существует процесс ETL? Какие цели он преследует?
Представьте компанию, которая содержит в себе каталог различных продуктов от разных Поставщиков. Для размещения этих продуктов в каталоге нужно получать различную информацию о них от разных Поставщиков: цена, остатки на складах и т.д. Для такого процесса характерно большое количество интеграций, каждая из которых характеризуется наличием «cобственного» процесса ETL.
Простым языком, что же происходит? Данные извлекаются, затем проходят процесс трансформации и поскольку форматы данных, которые хранятся у различных Поставщиков разные, крайне важно привести данные к некоему унифицированному виду, модели поведения, и, наконец, загрузить в БД.
Также ETL процессы должны отвечать некоторым требованиям бизнеса как то:
1️⃣ Решение по ETL процессам должно быть стандартным = максимально распространённым, чтобы облегчить работу с ним.
2️⃣ Быстрое внедрение новых интеграций. Т.е. изменение формата передачи новых данных не должно приводить к длительным процессам разработки, внедрения и т.д.
3️⃣ Адекватная стоимость. Стоимость разработки, внедрения не должна быть высокой = должна соответствовать формуле «один раз настроили — подняли — внедрили».
Какие технические вопросы могут возникнуть при внедрении процессов ETL?
✏️ Необходимость отслеживать состояние интеграций. Какие процессы сейчас работают, с какой скоростью и т.д.
✏️ Существуют движки для внедрения ETL, но они требуют доработок (админка, роли, логирование…)
✏️ Для построения ETL удобно использовать DAG – directed acyclic graph, который позволяет построить «дерево», у которого много разных ветвлений. Но этот движок требует много дополнительного программного обеспечения.
✏️ Как следствие возникает потребность в привлечении отдельного специалиста, который бы разобрался бы в том как движок работает и устроен, специалиста, который написал бы кучу кода для имплементации бизнес — логики, что является достаточно долгим и дорогостоящим процессом и иногда приводит к переписыванию значительной части кода.
✏️ Для построения ETL процессов часто используются отличные от используемых в компаниях языки программирования, соответственно, уходит время на то, чтобы разобраться с ними.
☝🏻 Таким образом, ETL процессы несут в себе большую значимость и ценность, но стоит хорошо подготовиться перед тем как начать работать с ними.
Полезная статья для начинающих аналитиков👉🏻
https://habr.com/ru/company/surfstudio/blog/594199/
https://habr.com/ru/company/surfstudio/blog/594199/
Хабр
Топ-5 заблуждений в работе аналитика
Чем занимается бизнес-аналитик? А кто его знает: какая-то мутная профессия. Это одно из заблуждений, которое — внезапно — высказывают не только клиенты… Но и коллеги внутри команды разработки, и даже...
Отличная вакансия для системных аналитиков‼️
Международная аутсорсинговая IT - компания Andersen в поисках Системных аналитиков для работы на русскоязычных проектах в доменах - банки, страхование, ритейл, логистика, нефтегаз и других!
Чем предстоит заниматься:
👉 сбор информации, выявление требований их анализ и оценка;
формирование проектной документации;
👉 анализ текущих процессов;
проработка технических и интеграционных решений.
👤 Каким видят подходящего кандидата:
Опыт работы СА и/или БА от 2-х лет
Опыт описания и реализации интеграций (будет преимуществом Web-Services, REST, SOAP-запросов, работа с брокерами сообщений и т.д.)
Знание принципов HTTP, XML/JSON, XSD/JSON схем
Опыт проектирования или участия в проектировании архитектуры приложений
Навык проектирования БД (ER-диаграмма), навык работы с объектами БД (функции, процедуры и т.д.), опыт работы с SQL и NoSQL БД
Навык работы с SQL-запросами (минимум join-ы и агрегатные функции)
Опыт использования BPMN, UML, IDEF1x и др.
Базовое понимание основ IT security, основ ООП
📞 Контактное лицо:
Лакисова Александра - рекрутер
Скайп live:.cid.9c86f9a0b0c8903
Телеграмм @a-lakisova
Международная аутсорсинговая IT - компания Andersen в поисках Системных аналитиков для работы на русскоязычных проектах в доменах - банки, страхование, ритейл, логистика, нефтегаз и других!
Чем предстоит заниматься:
👉 сбор информации, выявление требований их анализ и оценка;
формирование проектной документации;
👉 анализ текущих процессов;
проработка технических и интеграционных решений.
👤 Каким видят подходящего кандидата:
Опыт работы СА и/или БА от 2-х лет
Опыт описания и реализации интеграций (будет преимуществом Web-Services, REST, SOAP-запросов, работа с брокерами сообщений и т.д.)
Знание принципов HTTP, XML/JSON, XSD/JSON схем
Опыт проектирования или участия в проектировании архитектуры приложений
Навык проектирования БД (ER-диаграмма), навык работы с объектами БД (функции, процедуры и т.д.), опыт работы с SQL и NoSQL БД
Навык работы с SQL-запросами (минимум join-ы и агрегатные функции)
Опыт использования BPMN, UML, IDEF1x и др.
Базовое понимание основ IT security, основ ООП
📞 Контактное лицо:
Лакисова Александра - рекрутер
Скайп live:.cid.9c86f9a0b0c8903
Телеграмм @a-lakisova
Что такое Blockchain простыми словами?
☝🏻 Общеизвестный факт- мир становится цифровым. Также и деньги мы можем хранить их в кошельке, а можем и в интернете. Сейчас слово "криптовалюта" у всех на слуху.
Давайте же вместе разберёмся, что же такое Blockchain?
Мы живём в эпоху Интернета. Каждый из нас является пользователем интернета. На первый взгляд Интернет — штука полезная. Сомневаюсь, что кто - то может представить свою жизнь без него. Выглядит он достаточно привлекательно)), но с другой стороны интернет вещь ненадёжная. В нем все таки происходят взломы кражи т.д.
Так, например, если человек загрузил в интернет какой-то свой контент, он может и не принадлежать ему вовсе, а быть собственностью государства, крупной организации и т.д. Например, Инстаграмм. Все, что Вы "постите" Вам не принадлежит.
👉🏻 Одним словом, загрузка чего - то ценного может плохо кончится.
Проблемы такого рода нужно было решать. Таким образом и появился Blockchain.
Blockchain - технология распределённых реестров. Иными словами, хранилище данных которое никому не принадлежит никому. В этом хранилище есть блоки с записями, например, с записями о транзакциях. Когда один такой блок заполняется создаётся новый блок, который присоединяется к старым. Таким образом, возникает цепь блоков, т.е. Blockchain.
Записи в блоках очень сложно подделать,так как Blockchain одновременно хранится на множестве устройств. Если у кого-то какая то запись не совпадает с остальными она считается недействительной.
☝🏻 Все записи в Blockchain зашифрованы.
Можно с уверенностью сказать, что Blockchain это новый «Интернет ценностей», ведь основная ценность для которой была создана технология - деньги.
Вместе с появлением технологии распределённых реестров появилась первая электронная валюта - биткоин.
Возникает вопрос: можно ли считать криптовалюту деньгами?
Деньги рубли, доллары, евро и т.д. бумажная валюта. Их стоимость контролируется Центробанком,
💰 Криптовалюта - альтернатива бумажным деньгам. Но в отличии от бумажных валют, стоимость криптовалюты не зависит от политики конкретных государств. С учётом того, что в мире наблюдается снижения уровня веры в государственные институты, люди начинают все больше вкладываться в криптовалюту.
✔️Видимым преимуществом криптовалюты является тот факт , что это ещё и платёжная система, как Visa и Master Card. но для осуществления переводов в криптовалюте не нужен посредник, что бывает очень выгодно.
Отвечая на наш вопрос: «Криптовалюта это деньги?» можно с уверенностью сказать «Да!», но только в тех странах, где за криптовалюту можно официально покупать товары и услуги, а это Япония, Европа, США.
Эмисиия криптовалюты(выпуск) осуществляется засчёт майнинга. Суть майнинга заключается в том, что именно то устройство, которое быстрее всех решит криптографическую задачу получает небольшое количество криптовалюты. Майнеры соревнуются между собой в создании блоков. Таким образом и поддерживается Blockchain. Криптовалюты бывают разных видов. Для каждой криптовалюты существует свой Blockchain.
Подводя итог, хочется процитировать выдержку из одной из многочисленных статей про Blockchain, размещённых в Интернете:
«Биткоин это лишь один из множества проектов, который получил огромную известность благодаря сумасшедшему росту стоимости, весь этот «хайп» скрывает под собой великолепную технологию способную сделать мир лучше»
☝🏻 Общеизвестный факт- мир становится цифровым. Также и деньги мы можем хранить их в кошельке, а можем и в интернете. Сейчас слово "криптовалюта" у всех на слуху.
Давайте же вместе разберёмся, что же такое Blockchain?
Мы живём в эпоху Интернета. Каждый из нас является пользователем интернета. На первый взгляд Интернет — штука полезная. Сомневаюсь, что кто - то может представить свою жизнь без него. Выглядит он достаточно привлекательно)), но с другой стороны интернет вещь ненадёжная. В нем все таки происходят взломы кражи т.д.
Так, например, если человек загрузил в интернет какой-то свой контент, он может и не принадлежать ему вовсе, а быть собственностью государства, крупной организации и т.д. Например, Инстаграмм. Все, что Вы "постите" Вам не принадлежит.
👉🏻 Одним словом, загрузка чего - то ценного может плохо кончится.
Проблемы такого рода нужно было решать. Таким образом и появился Blockchain.
Blockchain - технология распределённых реестров. Иными словами, хранилище данных которое никому не принадлежит никому. В этом хранилище есть блоки с записями, например, с записями о транзакциях. Когда один такой блок заполняется создаётся новый блок, который присоединяется к старым. Таким образом, возникает цепь блоков, т.е. Blockchain.
Записи в блоках очень сложно подделать,так как Blockchain одновременно хранится на множестве устройств. Если у кого-то какая то запись не совпадает с остальными она считается недействительной.
☝🏻 Все записи в Blockchain зашифрованы.
Можно с уверенностью сказать, что Blockchain это новый «Интернет ценностей», ведь основная ценность для которой была создана технология - деньги.
Вместе с появлением технологии распределённых реестров появилась первая электронная валюта - биткоин.
Возникает вопрос: можно ли считать криптовалюту деньгами?
Деньги рубли, доллары, евро и т.д. бумажная валюта. Их стоимость контролируется Центробанком,
💰 Криптовалюта - альтернатива бумажным деньгам. Но в отличии от бумажных валют, стоимость криптовалюты не зависит от политики конкретных государств. С учётом того, что в мире наблюдается снижения уровня веры в государственные институты, люди начинают все больше вкладываться в криптовалюту.
✔️Видимым преимуществом криптовалюты является тот факт , что это ещё и платёжная система, как Visa и Master Card. но для осуществления переводов в криптовалюте не нужен посредник, что бывает очень выгодно.
Отвечая на наш вопрос: «Криптовалюта это деньги?» можно с уверенностью сказать «Да!», но только в тех странах, где за криптовалюту можно официально покупать товары и услуги, а это Япония, Европа, США.
Эмисиия криптовалюты(выпуск) осуществляется засчёт майнинга. Суть майнинга заключается в том, что именно то устройство, которое быстрее всех решит криптографическую задачу получает небольшое количество криптовалюты. Майнеры соревнуются между собой в создании блоков. Таким образом и поддерживается Blockchain. Криптовалюты бывают разных видов. Для каждой криптовалюты существует свой Blockchain.
Подводя итог, хочется процитировать выдержку из одной из многочисленных статей про Blockchain, размещённых в Интернете:
«Биткоин это лишь один из множества проектов, который получил огромную известность благодаря сумасшедшему росту стоимости, весь этот «хайп» скрывает под собой великолепную технологию способную сделать мир лучше»
Что такое БД и какие бывают БД?
Многие из нас так или иначе сталкивались с аббревиатурой БД - База Данных.
Давайте попробуем разобраться, что же это такое, какие типы БД бывают и как они используются.
✏️На самом деле базы данных окружают нас повсюду. Решили мы купить товар в интернет-магазине, оформить кредит или поставить автомобиль на учет в ГИБДД. Каждое из этих действий сопровождается взаимодействием с БД. Говоря простым языком, база данных - это набор сведений об объектах или предметной области реального мира хранящийся в электронном виде.
Тема Баз Данных получила свое развитие с середины 60х годов 20го века. Со сравнительно недавних пор человечество получило в свое распоряжение два основных вида БД - SQL и NoSQL.
На сегодняшний день существует множество типов БД.
1️⃣ Файловые БД - Информация хранится в файлах в виде текста разделенного спецсимволами. Обычно используется для хранения крайне небольших объемов информации. Пример - csv файл
2️⃣ Реляционная БД или SQL - Один из самых популярных типов БД. Данные хранятся в таблицах с набором полей (столбцов) в виде строк и связаны определенными типами отношений. Хорошо подходит для хранения структурированной информации. Пример - Oracle, MS SQL Server
3️⃣ Не реляционные БД - Данный тип БД имеет общую парадигму NoSQL для хранения плохо-структурируемых данных. Существует несколько подвидов хранение данных в каждом из них реализовано по-своему.
👉🏻 Рассмотрим их чуть подробнее:
📌 Документ-ориентированные БД - БД хранение данных в которой организовано с помощью коллекций данных. Обычно в формате JSON \ BSON или XML. В коллекциях вы можете хранить данные разного типа и в том объеме в котором захотите.
👉🏻 Пример - MongoDB
📌 Графовые БД - Принцип хранения данных в такой БД вытекает из самого названия. Т.е реализован на базе теории графов. Где узлы графа являются объектами БД а ребра - связями между ними с определенными свойствами.
👉🏻 Пример - Neo4j
📌 Key Value БД - Данные хранятся в формате ключ - значение или другими словами в виде ассоциативного массива. Где по ключу можно однозначно получить необходимые нам данные.
👉🏻 Пример - Redis
📌 Колоночные БД - В отличие от реляционных БД, где строки в таблицах БД строго определены количеством полей, типами данных итд Колоночные базы используют вместо таблиц структуры - колонки или семейства колонок, которые содержат идентификаторы - по ним можно получить соответствующие наборы данных.
👉🏻 Пример - Cassandra
Многие из нас так или иначе сталкивались с аббревиатурой БД - База Данных.
Давайте попробуем разобраться, что же это такое, какие типы БД бывают и как они используются.
✏️На самом деле базы данных окружают нас повсюду. Решили мы купить товар в интернет-магазине, оформить кредит или поставить автомобиль на учет в ГИБДД. Каждое из этих действий сопровождается взаимодействием с БД. Говоря простым языком, база данных - это набор сведений об объектах или предметной области реального мира хранящийся в электронном виде.
Тема Баз Данных получила свое развитие с середины 60х годов 20го века. Со сравнительно недавних пор человечество получило в свое распоряжение два основных вида БД - SQL и NoSQL.
На сегодняшний день существует множество типов БД.
1️⃣ Файловые БД - Информация хранится в файлах в виде текста разделенного спецсимволами. Обычно используется для хранения крайне небольших объемов информации. Пример - csv файл
2️⃣ Реляционная БД или SQL - Один из самых популярных типов БД. Данные хранятся в таблицах с набором полей (столбцов) в виде строк и связаны определенными типами отношений. Хорошо подходит для хранения структурированной информации. Пример - Oracle, MS SQL Server
3️⃣ Не реляционные БД - Данный тип БД имеет общую парадигму NoSQL для хранения плохо-структурируемых данных. Существует несколько подвидов хранение данных в каждом из них реализовано по-своему.
👉🏻 Рассмотрим их чуть подробнее:
📌 Документ-ориентированные БД - БД хранение данных в которой организовано с помощью коллекций данных. Обычно в формате JSON \ BSON или XML. В коллекциях вы можете хранить данные разного типа и в том объеме в котором захотите.
👉🏻 Пример - MongoDB
📌 Графовые БД - Принцип хранения данных в такой БД вытекает из самого названия. Т.е реализован на базе теории графов. Где узлы графа являются объектами БД а ребра - связями между ними с определенными свойствами.
👉🏻 Пример - Neo4j
📌 Key Value БД - Данные хранятся в формате ключ - значение или другими словами в виде ассоциативного массива. Где по ключу можно однозначно получить необходимые нам данные.
👉🏻 Пример - Redis
📌 Колоночные БД - В отличие от реляционных БД, где строки в таблицах БД строго определены количеством полей, типами данных итд Колоночные базы используют вместо таблиц структуры - колонки или семейства колонок, которые содержат идентификаторы - по ним можно получить соответствующие наборы данных.
👉🏻 Пример - Cassandra
Статья о том, как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.
https://scrumtrek.ru/blog/product-management/5615/behavior-driven-development/
https://scrumtrek.ru/blog/product-management/5615/behavior-driven-development/
Блог ScrumTrek
Behavior-Driven Development — статья в блоге ScrumTrek
Как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.
Отличия SQL и NoSQL баз данных
Если про SQL базы известно достаточно давно, то NoSQL появились сравнительно недавно и развиваются быстрыми темпами. У каждой из типов есть свои преимущества и недостатки, зная их, можно руководствоваться при выборе решения конкретной задачи при разработке или модификации существующей системы или сервиса.
➕ Плюсы SQL БД
✔️ Принцип ACID, который лежит в основе транзакционных систем. Он гласит, что данные должны быть
- Атомарными - то есть ни одна транзакция не должна быть завершена частично
- Консистентными - данные в системе не будут противоречивы за счет допустимых результатов выполнения транзакций
- Изолированными - это значит что каждая транзакция будет изолирована. т.е никакая другая в момент времени не сможет повлиять на выполнение текущей.
- Долговечными - все изменения производимые с данными в базе - сохраняются
✔️ Вертикальная масштабируемость - это значит, что если у вас растет нагрузка на базу или сама база то решить проблему можно просто сделав апгрейд сервера или например создать кластер чтобы вычисления производились еще и параллельно.
✔️ Стандартизированный язык для манипуляции с данными - SQL - вне зависимости от того какая СУБД перед вами MySQL MS SQL Oracle или PostgreSQL - язык плюс-минус будет одинаковым для всех типов с незначительными синтаксическими отличиями.
✔️ Простота внедрения - решения на базе SQL внедрять проще с точки зрения начальных затрат и последующей окупаемости.
➖ Теперь немного о минусах
➡️ Сложность настройки и сопровождения при больших объемах данных.
➡️ Негибкость - внесение изменений в структуру требуют большого времени и ресурсов.
➡️ Горизонтальная масштабируемость - сложность распределить таблицы с данными по разными серверам
➡️ Дорогое решение если говорить о возможности приобретения достаточно мощного сервера или серверов под большую нагрузку или размер базы.
➕ Плюсы NoSQL БД
✅ Возможность хранения больших неструктурированных данных
✅ Горизонтальное масштабирование - нет необходимости покупать более дорогой сервер при увеличении нагрузки на базу или ее роста.
✅ Легкость внесения изменений в существующую структуру хранения. Нет ограничений на типы данных и строгой привязки к схемам
✅ Простая репликация - это означает что можно копировать измененные данные на другие сервера.
✅ Шардинг - то есть информация в БД будет разделена по разным узлам сети. При этом каждый узел будет отвечать только за свой набор данных и манипуляции с ними
Скорость и простота разработки
➖ Немного о минусах
▶️ Привязка конкретной NoSQL СУБД к определенному синтаксису для выполнения манипуляций с данными
▶️ Сложность проектирования моделей данных и внедрения технологии
▶️ Не очень хорошая предсказуемость с точки зрения возникновения узких мест в спроектированных системах
▶️ Обеспечение достаточной целостности данных - в отличие от реляционных БД имеется риск потери данных или их плохая консистентность
Нет волшебной таблетки по использованию 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
Будет полезно для:
- 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/
https://habr.com/ru/company/click/blog/651393/
Хабр
Тестируем популярные методы тайм-менеджмента. Часть 1: тайм-блокинг, матрица Эйзенхауэра, «1-3-5» и помидоры
Привет, Хабр! Сегодня мы будем проводить эксперименты на живых людях! Точнее, эксперименты уже проведены, и расскажет о них Анна, маркетолог и один из авторов контента Click.ru . До сотрудничества с...
Три главных боли аналитика (и не только).
Статья от системного аналитика Кристины Горбуновой о том, с какими трудностями может столкнуться аналитик во время своей работы и как с этим справиться.
👉🏻 Боль №1.
Оценки сроков проекта сделана до тебя, а соблюдать их нужно тебе
Сразу по самому больному, да)
☝🏻 Почему так бывает:
а) Оценку делали не по хорошим формулам (где к первой оценке прибавляют 40%), а по плохим формулам (делят на два). То есть, сроки спустили сверху.
б) Сюр или так еще бывает? Оценку делал человек, который считает, что приложение для банка можно сделать за два месяца. И добавить кнопочку - это просто нарисовать кнопочку) Никакого тебе фронта, API, бэка, очередей…
🔥 Что можно сделать:
📎 Рассказать, что именно скрывается за работой аналитика : продумать и прописать подробную логику, учесть все связи требований, архитектуру и масштабирование проекта, поговорить с кучей людей и синтезировать их требования;
📎 Взять важную задачу и провести по ней нормальную оценку. Экстраполировать на остальные. Аргументировать. Найти авторитетную поддержку своим срокам;
📎 После первой итерации, если/когда сроки провалены, сделать картинку “Ожидание VS Реальность”. Предложить другую оценку, обосновать;
📎 Урезать требования. Тут важно понять, какие требования высечены в камне, а какие можно подвинуть. Как понять? По реакции заказчика, когда начинаешь их резать)
📎 Увеличивать свою эффективность;
📎 Расширять команду;
📎 Перерабатывать;
📎 Увольняться/менять проект (я серьезно, но пункт последний в списке не зря).
👉🏻 Боль №2.
Погружение в новый проект.
Горы документации, часто неактуальной; куча людей, из которых надо вытащить то, что не написано в документации; тестирование API, селекты в БД, чтение кода….Все для того, чтобы разобраться)
🔥 Что можно сделать:
📎 Составить общую схему всего. Неважно, если вы ее забросите. Важно, что составление схемы - это ВАШ процесс погружения в проект, раскладывание по полочкам в вашей голове. Главное - делать что-нибудь с этой информацией, а не только сгружать ее в мозг.
📎 Помнить, что изучение и обработка информации - это разные процессы для мозга. Поэтому, устраивайте себе передышки, желательно физические - сделать несколько упражнений, посмотреть в окно, пройтись, полежать с закрытыми глазами. На одной работе у нас была коллективная практика - каждый час 5 минут мы стояли в планке)
📎 Важно понимать, что пока вы отдыхаете, вы даете мозгу время для обработки информации, а не отлыниваете от работы. Почитать фэйсбук или инстаграмм - для мозга отдыхом не является.
👉🏻 Боль №3.
Изменение требований.
☝🏻 Почему так бывает, мы все знаем. Бизнес живой, софт живой, всё бежит и меняется.
🔥 Что делаем:
Чем проще проект, тем больше всего можно держать в голове. Несколько ключевых людей проекта знают, что с чем связано и почему. Но проекты всегда растут, и поэтому этот способ несет приличные риски. И еще, голова нужна не для хранения информации, а для того, чтобы ею думать)
Разберем два понятия - связанность (трассировка) и изменение требований.
📎 Трассировка требований - знать, а лучше задокументировать, как связаны требования. Мы должны “это” отобразить на интерфейсе клиенту, а значит “это” надо откуда-то взять. И дальше по цепочке - откуда берем, как обрабатываем, куда складываем.
📎 Изменение требований - когда меняется любой элемент в этой цепочке.
Нужно создать свою систему отслеживания связей требований, и тогда при любом изменении будет видно, что оно за собой потянет.
Эта тема заслуживает отдельной большой статьи. 📍Как минимум, связь можно отслеживать в созданной таблице. 📍Как максимум - есть инструменты IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Статья от системного аналитика Кристины Горбуновой о том, с какими трудностями может столкнуться аналитик во время своей работы и как с этим справиться.
👉🏻 Боль №1.
Оценки сроков проекта сделана до тебя, а соблюдать их нужно тебе
Сразу по самому больному, да)
☝🏻 Почему так бывает:
а) Оценку делали не по хорошим формулам (где к первой оценке прибавляют 40%), а по плохим формулам (делят на два). То есть, сроки спустили сверху.
б) Сюр или так еще бывает? Оценку делал человек, который считает, что приложение для банка можно сделать за два месяца. И добавить кнопочку - это просто нарисовать кнопочку) Никакого тебе фронта, API, бэка, очередей…
🔥 Что можно сделать:
📎 Рассказать, что именно скрывается за работой аналитика : продумать и прописать подробную логику, учесть все связи требований, архитектуру и масштабирование проекта, поговорить с кучей людей и синтезировать их требования;
📎 Взять важную задачу и провести по ней нормальную оценку. Экстраполировать на остальные. Аргументировать. Найти авторитетную поддержку своим срокам;
📎 После первой итерации, если/когда сроки провалены, сделать картинку “Ожидание VS Реальность”. Предложить другую оценку, обосновать;
📎 Урезать требования. Тут важно понять, какие требования высечены в камне, а какие можно подвинуть. Как понять? По реакции заказчика, когда начинаешь их резать)
📎 Увеличивать свою эффективность;
📎 Расширять команду;
📎 Перерабатывать;
📎 Увольняться/менять проект (я серьезно, но пункт последний в списке не зря).
👉🏻 Боль №2.
Погружение в новый проект.
Горы документации, часто неактуальной; куча людей, из которых надо вытащить то, что не написано в документации; тестирование API, селекты в БД, чтение кода….Все для того, чтобы разобраться)
🔥 Что можно сделать:
📎 Составить общую схему всего. Неважно, если вы ее забросите. Важно, что составление схемы - это ВАШ процесс погружения в проект, раскладывание по полочкам в вашей голове. Главное - делать что-нибудь с этой информацией, а не только сгружать ее в мозг.
📎 Помнить, что изучение и обработка информации - это разные процессы для мозга. Поэтому, устраивайте себе передышки, желательно физические - сделать несколько упражнений, посмотреть в окно, пройтись, полежать с закрытыми глазами. На одной работе у нас была коллективная практика - каждый час 5 минут мы стояли в планке)
📎 Важно понимать, что пока вы отдыхаете, вы даете мозгу время для обработки информации, а не отлыниваете от работы. Почитать фэйсбук или инстаграмм - для мозга отдыхом не является.
👉🏻 Боль №3.
Изменение требований.
☝🏻 Почему так бывает, мы все знаем. Бизнес живой, софт живой, всё бежит и меняется.
🔥 Что делаем:
Чем проще проект, тем больше всего можно держать в голове. Несколько ключевых людей проекта знают, что с чем связано и почему. Но проекты всегда растут, и поэтому этот способ несет приличные риски. И еще, голова нужна не для хранения информации, а для того, чтобы ею думать)
Разберем два понятия - связанность (трассировка) и изменение требований.
📎 Трассировка требований - знать, а лучше задокументировать, как связаны требования. Мы должны “это” отобразить на интерфейсе клиенту, а значит “это” надо откуда-то взять. И дальше по цепочке - откуда берем, как обрабатываем, куда складываем.
📎 Изменение требований - когда меняется любой элемент в этой цепочке.
Нужно создать свою систему отслеживания связей требований, и тогда при любом изменении будет видно, что оно за собой потянет.
Эта тема заслуживает отдельной большой статьи. 📍Как минимум, связь можно отслеживать в созданной таблице. 📍Как максимум - есть инструменты IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM.
Рекомендация от автора нашей последней статьи: статья от Татьяны Крутовой, как быстро погрузиться в проект с "историей".
http://orderskills.ru/project-with-story/
http://orderskills.ru/project-with-story/
С какими проблемами вы сталкивались как аналитик во время своей работы?
(можно выбрать несколько ответов)
(можно выбрать несколько ответов)
Anonymous Poll
31%
Некорректная оценка сроков, сделанная до вас
39%
Недостаточное сотрудничество или отсутствие поддержки от стейкхолдеров
38%
Незнание предметной области/слишком сложный проект с технической стороны
43%
Вход на новый проект без какой-либо готовой документации по нему/недостаточный онбординг
23%
Проблемы, связанные с командой (трудная коммуникация\недостаточный профессионализм и т.д.)
38%
Слишком частое изменения требований от заказчика
48%
Отсутствие налаженных процессов на проекте/обязанности аналитика четко не обозначены
7%
Другое (можете поделиться в комментариях)
Одна из проблем, с которой может столкнуться бизнес аналитик, это недооцененность его роли заказчиками.
Причины, по которым так происходит, и как с этим справиться, рассказывается в статье 👉🏻
https://habr.com/ru/company/surfstudio/blog/655077/
Причины, по которым так происходит, и как с этим справиться, рассказывается в статье 👉🏻
https://habr.com/ru/company/surfstudio/blog/655077/
Хабр
Бизнес-анализ и мобильные приложения: почему заказчики не видят ценности в аналитике и как им её донести
Часто заказчики не понимают ценности бизнес-аналитика. Кажется, что эти функции могут выполнять другие члены команды: разработчики, тестировщики, менеджеры проектов. Мы уже затрагивали эту тему в...
Подробная статья на английском языке, как пройти сертификацию PSPO успешно, от Кристины Юнчиц, бизнес аналитика в компании Andersen.
👉🏻 В статье приведены лучшие практики и методы подготовки, а также масса полезных ссылок.
❗️Все, что нужно, чтобы сдать на PSPO с первого раза!
https://telegra.ph/How-to-pass-PSPO-successfully-04-08
👉🏻 В статье приведены лучшие практики и методы подготовки, а также масса полезных ссылок.
❗️Все, что нужно, чтобы сдать на PSPO с первого раза!
https://telegra.ph/How-to-pass-PSPO-successfully-04-08
Telegraph
How to pass PSPO successfully?
“If you’re someone who is comfortable with the "business side" of projects, you are probably the right person to aim for a Certified Scrum Product Owner® certification. -Scrum Alliance Why you need it? How to pass PSPO (Professional Scrum Product Owner) certificate…