Базовая модель коммуникации в работе аналитика.
📍 Учитывая, что коммуникации занимают иногда 80 процентов рабочего времени аналитика, выстраивать её нужно грамотно, дабы максимизировать эффективность передачи информации. Не будем забывать одна из черт, которыми должен обладать хороший аналитик именно «коммуникативность» (P.S. не путаем с «коммуникабельностью»)). Коммуницировать нужно качественно, без потерь и при этом не затрачивая на это лишнее ресурсы.
👉🏻 Давайте рассмотрим базовую модель коммуникации.
➡️ Есть два участника «Отправитель» и «Получатель», которые обмениваются между собой информацией. Что же происходит дальше?
1️⃣ Отправитель кодирует сообщение, т. е. излагает сообщение на языке, предположительно понятном «Получателю».
На данном этапе не стоит забывать про проактивность. Для того, чтобы коммуникация носила в последующем эффективный характер аналитик должен осуществить кодировку на языке максимально близком «Получателю». Для команды разработки это технический язык в терминах специализации. Для Заказчика это бизнес язык в терминах доменной области бизнеса. Также нужно использовать визуальные средства, с учётом тог, что большинство людей тяжело воспринимают «сухой» текст, а именно схемы, диаграммы, флипчарты и т. д. Само собой, мысль нужно формулировать чётко, лаконично, информативно, логично и последовательно.
2️⃣ С помощью канала сообщение передаётся «Получателю». Устно, по телефону, по почте. В процессе передачи сообщения искажаются каналом коммуникации. Соответственно искажения или шум это все, что может помешать передаче и пониманию сообщения. (например, помехи во время телефонного разговора).
📌 Основная задача аналитика на данном этапе — предупредить, минимизировать возникновение шума. Для этого важно выбрать максимально эффективный канал коммуникации. Сюда же можно отнести совершенствование знание языка аналитиком, проверка телефонной связи перед разговором, выбор и тестирование микрофона для связи по Skype и т.д. Идеально, перед началом коммуникации обдумать спектр помех, и то как можно их минимизировать.
3️⃣ На стороне «Получателя» происходит декодирование информации = преобразование сообщения «Получателем» в понятные ему мысли и идеи. На успешность этого этапа аналитик вряд ли может повлиять, кроме того, как закодировать сообщение таким образом, чтобы максимально облегчить декодировку.
4️⃣ В хорошем процессе коммуникации также присутствует обратная связь. Т.е. обратное сообщение об успешности декодировки и приёма исходного сообщения. (Например, ответ по электронной почте, о том, что сообщение получено)
☝🏻 Важно:
📌 обратная связь должна быть. Аналитик должен простимулировать «Получателя» дать обратную связь;
📌 использование обратной связи помогает скорректировать коммуникацию. Во время устного общения полезно следить за невербаликой (менять тон, темп). После презентации документации требований разработчикам крайне продуктивным является назначение митинга с целью получить обратную связь и оценить восприятие документа командой и, возможно внести правки для улучшения этого самого восприятия.
📍Не стоит забывать, что за все коммуникации на проекте отвечает именно аналитик. Выстраивайте коммуникации правильно!
📍 Учитывая, что коммуникации занимают иногда 80 процентов рабочего времени аналитика, выстраивать её нужно грамотно, дабы максимизировать эффективность передачи информации. Не будем забывать одна из черт, которыми должен обладать хороший аналитик именно «коммуникативность» (P.S. не путаем с «коммуникабельностью»)). Коммуницировать нужно качественно, без потерь и при этом не затрачивая на это лишнее ресурсы.
👉🏻 Давайте рассмотрим базовую модель коммуникации.
➡️ Есть два участника «Отправитель» и «Получатель», которые обмениваются между собой информацией. Что же происходит дальше?
1️⃣ Отправитель кодирует сообщение, т. е. излагает сообщение на языке, предположительно понятном «Получателю».
На данном этапе не стоит забывать про проактивность. Для того, чтобы коммуникация носила в последующем эффективный характер аналитик должен осуществить кодировку на языке максимально близком «Получателю». Для команды разработки это технический язык в терминах специализации. Для Заказчика это бизнес язык в терминах доменной области бизнеса. Также нужно использовать визуальные средства, с учётом тог, что большинство людей тяжело воспринимают «сухой» текст, а именно схемы, диаграммы, флипчарты и т. д. Само собой, мысль нужно формулировать чётко, лаконично, информативно, логично и последовательно.
2️⃣ С помощью канала сообщение передаётся «Получателю». Устно, по телефону, по почте. В процессе передачи сообщения искажаются каналом коммуникации. Соответственно искажения или шум это все, что может помешать передаче и пониманию сообщения. (например, помехи во время телефонного разговора).
📌 Основная задача аналитика на данном этапе — предупредить, минимизировать возникновение шума. Для этого важно выбрать максимально эффективный канал коммуникации. Сюда же можно отнести совершенствование знание языка аналитиком, проверка телефонной связи перед разговором, выбор и тестирование микрофона для связи по Skype и т.д. Идеально, перед началом коммуникации обдумать спектр помех, и то как можно их минимизировать.
3️⃣ На стороне «Получателя» происходит декодирование информации = преобразование сообщения «Получателем» в понятные ему мысли и идеи. На успешность этого этапа аналитик вряд ли может повлиять, кроме того, как закодировать сообщение таким образом, чтобы максимально облегчить декодировку.
4️⃣ В хорошем процессе коммуникации также присутствует обратная связь. Т.е. обратное сообщение об успешности декодировки и приёма исходного сообщения. (Например, ответ по электронной почте, о том, что сообщение получено)
☝🏻 Важно:
📌 обратная связь должна быть. Аналитик должен простимулировать «Получателя» дать обратную связь;
📌 использование обратной связи помогает скорректировать коммуникацию. Во время устного общения полезно следить за невербаликой (менять тон, темп). После презентации документации требований разработчикам крайне продуктивным является назначение митинга с целью получить обратную связь и оценить восприятие документа командой и, возможно внести правки для улучшения этого самого восприятия.
📍Не стоит забывать, что за все коммуникации на проекте отвечает именно аналитик. Выстраивайте коммуникации правильно!
Топ 6 книг по Agile для бизнес аналитика.
👉🏻 Если вы хотите пополнить свои знания в сфере Agile, то следующие книги точно для вас:
📌 Дженнифер Грин , Эндрю Стеллман-Постигая Agile.Ценности, принципы, методологии.
Эта книга рассказывает о самых популярных agile-методологиях – Scrum, XP (экстремальном программировании), Lean (бережливом программировании) и Канбан. Она познакомит с методами Agile, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут команде полностью изменить свой подход к работе над проектами. Книга легко читается,отлично подходит для первого знакомства с agile-методологиями.
📌 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство.
Эта книга -библия в управлении проектами, которую полезно прочитать и бизнес аналитикам тоже. В шестое издание впервые включены указания по применению надлежащих практик управления проектами в гибких (agile) и адаптивных средах.
📌 Роберт Мартин-Чистый Agile. Основы гибкости.
«Чистый Agile» рассказывает, как применять на практике agile разработчикам, тестировщикам, аналитикам, руководителям, менеджерам проектов и клиентам.
📌 Henrik Kniberg.Скрам и XP заметки с передовой.
Классическая книга про опыт одной компании во внедрении Agile процессов. Настолько популярна, что переведена на все языки. Небольшая. Cчитается одним из лучших практических пособий по Scrum в области разработки ПО.
📌 Jeffrey Liker.Dao Toyota. История появления TPS (который потом назвали Lean) на фабриках Тойоты Читается легко и быстро. Рекомендуется к прочтению в качестве художественной литературы.
📌 David Anderson.Kanban. Фундаментальная книга про Kanban от его автора. В Lean/Kanban сообществе ее называют "Библия Kanban”. Книга, которая может дать четкое представление об этой agile-методологии.
Если вы знаете еще хорошие книги, можете поделиться ими в комментариях.
👉🏻 Если вы хотите пополнить свои знания в сфере Agile, то следующие книги точно для вас:
📌 Дженнифер Грин , Эндрю Стеллман-Постигая Agile.Ценности, принципы, методологии.
Эта книга рассказывает о самых популярных agile-методологиях – Scrum, XP (экстремальном программировании), Lean (бережливом программировании) и Канбан. Она познакомит с методами Agile, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут команде полностью изменить свой подход к работе над проектами. Книга легко читается,отлично подходит для первого знакомства с agile-методологиями.
📌 Руководство к своду знаний по управлению проектами (Руководство PMBOK®). Шестое издание. Agile: практическое руководство.
Эта книга -библия в управлении проектами, которую полезно прочитать и бизнес аналитикам тоже. В шестое издание впервые включены указания по применению надлежащих практик управления проектами в гибких (agile) и адаптивных средах.
📌 Роберт Мартин-Чистый Agile. Основы гибкости.
«Чистый Agile» рассказывает, как применять на практике agile разработчикам, тестировщикам, аналитикам, руководителям, менеджерам проектов и клиентам.
📌 Henrik Kniberg.Скрам и XP заметки с передовой.
Классическая книга про опыт одной компании во внедрении Agile процессов. Настолько популярна, что переведена на все языки. Небольшая. Cчитается одним из лучших практических пособий по Scrum в области разработки ПО.
📌 Jeffrey Liker.Dao Toyota. История появления TPS (который потом назвали Lean) на фабриках Тойоты Читается легко и быстро. Рекомендуется к прочтению в качестве художественной литературы.
📌 David Anderson.Kanban. Фундаментальная книга про Kanban от его автора. В Lean/Kanban сообществе ее называют "Библия Kanban”. Книга, которая может дать четкое представление об этой agile-методологии.
Если вы знаете еще хорошие книги, можете поделиться ими в комментариях.
Интересные размышления о мозговом штурме, ☝🏻 полезен ли данный метод или нет.
https://habr.com/ru/post/599175/
https://habr.com/ru/post/599175/
Хабр
Мозговой штурм не работает. Почему его до сих пор используют?
Давайте представим себе ситуацию: группе экспертов нужно решить сложную задачу. Она необычная и не решается стандартными способами. Одна из самых распространённых методик поиска решения таких задач —...
Сегодня поговорим о такой важном артефакте, как контекстная диаграмма.
👉🏻 Контекстная диаграмма - это диаграмма, которая используется для общего описания системы и описания ее взаимодействия с внешней средой. Диаграмма отображает интерфейс проектируемой системы с внешним миром, а именно, потоки данных между системой и внешними сущностями, с которыми она взаимодействует. Создается в начале проекта и представляет всю систему, как единый процесс.
🖍 Для построения контекстной диаграммы используется в основном нотация IDEF0 и DFD.
🖍 Цели построения диаграммы:
✔️ определить границы системы;
✔️ выявить функциональные требования, основываясь на входящий и исходящих потоках данных.
🖍 Элементы контекстной диаграммы:
✔️ проектируемый объект (система) - отображается в виде круга/овала;
✔️ внешние сущности, взаимодействующие с проектируемым объектом (пользователи, смежные системы) - отображаются в виде прямоугольников;
✔️ потоки данных (исходящие и входящие) - отображаются в виде стрелок.
🖍 Шаги построения диаграммы:
1️⃣ Запишите название проектируемой системы в центре;
2️⃣ Запишите внешние сущности, которые взаимодействуют с проектируемой системой вокруг проектируемой системы;
3️⃣ Укажите входящие и исходящие потоки данных между проектируемой системой и внешними сущностями с помощью стрелок;
3️⃣ Добавьте комментарий к потокам данных: детализируйте входящие и исходящие данные.
🖍 Онлайн-инструменты для создания контекстной диаграммы:
✔️ Google Draw,
✔️ Draw.io,
✔️ Miro.
- Рисунок контекстной диаграммы взят из интернета.
👉🏻 Контекстная диаграмма - это диаграмма, которая используется для общего описания системы и описания ее взаимодействия с внешней средой. Диаграмма отображает интерфейс проектируемой системы с внешним миром, а именно, потоки данных между системой и внешними сущностями, с которыми она взаимодействует. Создается в начале проекта и представляет всю систему, как единый процесс.
🖍 Для построения контекстной диаграммы используется в основном нотация IDEF0 и DFD.
🖍 Цели построения диаграммы:
✔️ определить границы системы;
✔️ выявить функциональные требования, основываясь на входящий и исходящих потоках данных.
🖍 Элементы контекстной диаграммы:
✔️ проектируемый объект (система) - отображается в виде круга/овала;
✔️ внешние сущности, взаимодействующие с проектируемым объектом (пользователи, смежные системы) - отображаются в виде прямоугольников;
✔️ потоки данных (исходящие и входящие) - отображаются в виде стрелок.
🖍 Шаги построения диаграммы:
1️⃣ Запишите название проектируемой системы в центре;
2️⃣ Запишите внешние сущности, которые взаимодействуют с проектируемой системой вокруг проектируемой системы;
3️⃣ Укажите входящие и исходящие потоки данных между проектируемой системой и внешними сущностями с помощью стрелок;
3️⃣ Добавьте комментарий к потокам данных: детализируйте входящие и исходящие данные.
🖍 Онлайн-инструменты для создания контекстной диаграммы:
✔️ Google Draw,
✔️ Draw.io,
✔️ Miro.
- Рисунок контекстной диаграммы взят из интернета.
Сегодня мы поговорим про такой интересный и полезный для БА инструмент как Lean Canvas.
➡️ Lean Canvas - это одностраничный шаблон, который кратко описывает бизнес-модель и представляет ключевую информацию о продукте без лишних деталей. Заполнив его, БА и вся команда продукта получают мощный инструмент, который позволяет посмотреть на продукт со всех сторон и перейти от идеи к чёткому плану действий.
📍Шаблон Lean Canvas состоит из 9 блоков. Для заполнения нужно последовательно пройти по каждому блоку, ответив на вопросы. Лучше всего заполнять блоки, собравшись всей командой и устроив мозговой штурм - это займет больше времени, но даст лучший результат.
📎 Содержание шаблона можно менять, но стандартная схема включает следующие блоки:
1️⃣ Целевая аудитория: “Для кого мы создаем свой продукт?”. Модель следует составлять отдельно для каждого сегмента целевой аудитории.
📌 Советы: Избегайте слишком широкого определения ЦА. Выделите “ранних пользователей”, которые первыми получат доступ к продукту и обеспечат быструю обратную связь.
2️⃣ Проблема, которую будет решать продукт: “Какая проблема есть у наших клиентов?”, “Кто сейчас помогает им решать эту проблему?”.
📌 Советы: Найдите альтернативные варианты решения, это не всегда очевидно, но любая проблема, как правило, уже как-то решается. Для анализа используйте подход Jobs To Be Done и инструмент CJM.
3️⃣ Потоки прибыли: “Каким образом продукт будет приносить деньги?”, “Какая модель получения доходов будет использоваться?”.
📌 Советы: Большинство продуктов создается ради прибыли, поэтому ориентируйтесь на особенности своих пользователей, изучите опыт успешных конкурентов.
4️⃣ Решение проблемы: “Как мы будем решать проблему пользователей?”, “Какие функции продукта будут этому способствовать?”.
📌 Советы: Подключите группу тестовых пользователей, проведите исследования, используйте аналитику и проверку гипотез.
5️⃣ Уникальная ценность будущего продукта: “Чем наш продукт будет отличаться от конкурентов?”, “Почему пользователи выберут нас?”. Сформулируйте идею в 1-3 коротких предложениях.
📌 Советы: Проверьте себя на группе тестовых пользователей - действительно ли вы нашли то, что заставит пользователей выбрать вас?
6️⃣ Каналы продвижения: “Как мы будем выстраивать коммуникацию с пользователями?”, “Как они узнают о нашем продукте?”.
📌 Советы: Продумайте, где у вашего продукта наибольшие шансы попасться на глаза будущим пользователям.
7️⃣ Ключевые метрики: “Как мы поймем, что наш продукт успешен?”, “Какими параметрами будет измеряться успех?”.
📌 Советы: Выделите минимальные критерии успеха - тот минимум, который позволит утверждать, что продукт стал успешным.
8️⃣ Структура затрат: “Какие затраты на продукт ожидаются?”, “Сколько денег понадобится для его запуска/развития?”.
📌 Советы: расходы могут быть фиксированными (налоги) или изменяющимися (стоимость материалов или работ) - продумайте каждый тип и определите если не конкретные суммы, то хотя бы статьи будущих расходов.
9️⃣ Скрытое преимущество: “Что позволит нам быть успешнее конкурентов?”, “Каков наш скрытый козырь?”. Это могут быть суперпрофессионалы в вашей команде, продвинутые технологии, большая клиентская база либо уникальные функции.
📌 Советы: Если вы планируете быть первыми на рынке в своем сегменте, не указывайте это как уникальное преимущество. Многие успешные продукты были далеко не первыми в своем деле.
✏️ Составлять Lean Canvas можно на бумаге либо воспользоваться одной из онлайн-программ, таких как Miro, Mural, Canvanizer.
📎 Lean Canvas можно использовать не только для понимания того, какой продукт, зачем и для кого будет создаваться. Он помогает понять, стоит ли вообще создавать продукт и избежать затрат на разработку заведомо ненужного продукта. Для уже созданного продукта этот инструмент поможет провести анализ, чтобы обнаружить потенциальные проблемы и определить будущие шаги.
📍Lean Canvas может стать мощным инструментом в арсенале любого БА, позволяя ему предлагать релевантные решения и создавать по-настоящему качественные и успешные продукты.
➡️ Lean Canvas - это одностраничный шаблон, который кратко описывает бизнес-модель и представляет ключевую информацию о продукте без лишних деталей. Заполнив его, БА и вся команда продукта получают мощный инструмент, который позволяет посмотреть на продукт со всех сторон и перейти от идеи к чёткому плану действий.
📍Шаблон Lean Canvas состоит из 9 блоков. Для заполнения нужно последовательно пройти по каждому блоку, ответив на вопросы. Лучше всего заполнять блоки, собравшись всей командой и устроив мозговой штурм - это займет больше времени, но даст лучший результат.
📎 Содержание шаблона можно менять, но стандартная схема включает следующие блоки:
1️⃣ Целевая аудитория: “Для кого мы создаем свой продукт?”. Модель следует составлять отдельно для каждого сегмента целевой аудитории.
📌 Советы: Избегайте слишком широкого определения ЦА. Выделите “ранних пользователей”, которые первыми получат доступ к продукту и обеспечат быструю обратную связь.
2️⃣ Проблема, которую будет решать продукт: “Какая проблема есть у наших клиентов?”, “Кто сейчас помогает им решать эту проблему?”.
📌 Советы: Найдите альтернативные варианты решения, это не всегда очевидно, но любая проблема, как правило, уже как-то решается. Для анализа используйте подход Jobs To Be Done и инструмент CJM.
3️⃣ Потоки прибыли: “Каким образом продукт будет приносить деньги?”, “Какая модель получения доходов будет использоваться?”.
📌 Советы: Большинство продуктов создается ради прибыли, поэтому ориентируйтесь на особенности своих пользователей, изучите опыт успешных конкурентов.
4️⃣ Решение проблемы: “Как мы будем решать проблему пользователей?”, “Какие функции продукта будут этому способствовать?”.
📌 Советы: Подключите группу тестовых пользователей, проведите исследования, используйте аналитику и проверку гипотез.
5️⃣ Уникальная ценность будущего продукта: “Чем наш продукт будет отличаться от конкурентов?”, “Почему пользователи выберут нас?”. Сформулируйте идею в 1-3 коротких предложениях.
📌 Советы: Проверьте себя на группе тестовых пользователей - действительно ли вы нашли то, что заставит пользователей выбрать вас?
6️⃣ Каналы продвижения: “Как мы будем выстраивать коммуникацию с пользователями?”, “Как они узнают о нашем продукте?”.
📌 Советы: Продумайте, где у вашего продукта наибольшие шансы попасться на глаза будущим пользователям.
7️⃣ Ключевые метрики: “Как мы поймем, что наш продукт успешен?”, “Какими параметрами будет измеряться успех?”.
📌 Советы: Выделите минимальные критерии успеха - тот минимум, который позволит утверждать, что продукт стал успешным.
8️⃣ Структура затрат: “Какие затраты на продукт ожидаются?”, “Сколько денег понадобится для его запуска/развития?”.
📌 Советы: расходы могут быть фиксированными (налоги) или изменяющимися (стоимость материалов или работ) - продумайте каждый тип и определите если не конкретные суммы, то хотя бы статьи будущих расходов.
9️⃣ Скрытое преимущество: “Что позволит нам быть успешнее конкурентов?”, “Каков наш скрытый козырь?”. Это могут быть суперпрофессионалы в вашей команде, продвинутые технологии, большая клиентская база либо уникальные функции.
📌 Советы: Если вы планируете быть первыми на рынке в своем сегменте, не указывайте это как уникальное преимущество. Многие успешные продукты были далеко не первыми в своем деле.
✏️ Составлять Lean Canvas можно на бумаге либо воспользоваться одной из онлайн-программ, таких как Miro, Mural, Canvanizer.
📎 Lean Canvas можно использовать не только для понимания того, какой продукт, зачем и для кого будет создаваться. Он помогает понять, стоит ли вообще создавать продукт и избежать затрат на разработку заведомо ненужного продукта. Для уже созданного продукта этот инструмент поможет провести анализ, чтобы обнаружить потенциальные проблемы и определить будущие шаги.
📍Lean Canvas может стать мощным инструментом в арсенале любого БА, позволяя ему предлагать релевантные решения и создавать по-настоящему качественные и успешные продукты.
Используете ли Вы Lean Canvas в своей работе?
Anonymous Poll
5%
Да, постоянно
20%
Один-пару раз за свою практику
23%
Нет, но хочу использовать
15%
Нет, мне это не нужно
38%
Нет,я даже не знал(а) про этот инструмент
Маечная система оценок👕. Что это и как
Использование размеров футболок для оценки проектов
👉🏻 В руководстве по Scrum нет официального правила относительно того, как команда должна оценивать и измерять предстоящий объем работ. Можно использовать покер планирование, метод Дельфи, метод функциональных точек или диаграмму Ганта. В одной из статей мы уже рассмотрели наиболее популярную систему оценок задач в Story Points, которая отлично работает на практике.
☝🏻 На этот раз предлагаем вашему вниманию альтернативную технику - оценку задач в размерах футболки (маечную оценку или T-shirt sizes). Популярность данной техники обусловлена скоростью использования (за одну сессию можно оценить 10-15 историй), а также легкостью ее применения.
Для сравнения, при оценке в Story Points используется около 10 значений из последовательности Фибоначчи, это действительно много, и давать такой огромный выбор зачастую бессмысленно. Но все носят футболки, поэтому сотрудникам будет просто понять разницу между размером XS и L.
Использование этих размеров для оценки трудозатрат на инициативы команды — быстрый способ получить представление о том, сколько времени и сил потребуется на разработку без применения сложных расчетов. Посмотрим, как это работает:
👉🏻 В качестве единицы измерения используется размер футболки: S, M, L, XL (если крупный проект, то еще XXS, XS, XXL). При желании можно договориться о соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее. Команда принимает решение о размере пользовательской истории или функции в ходе совместной открытой дискуссии
🖍 Обычно первые несколько задач оцениваются предварительно или используется предыдущий опыт оценки задачи: определяются наименьшие относительно остальных задачи и принимаются за XS размер. После этого оставшиеся задачи оцениваются уже с точки зрения насколько они больше XS. В зависимости от этого им присваивается определенный размер: S, M, L и тд
Присвоение истории размера XXL свидетельствует о том, что на самом деле невозможно оценить задачу, т.к. она нуждается в дальнейшей декомпозиции и уточнении
Сам процесс оценки соответствует покер планированию:
✔️ владелец продукта представляет историю/эпик, дает краткое описание
✔️ участники команды задают вопросы и обсуждают, чтобы лучше ее понять
✔️ все участники одновременно дают свою оценку по данной задаче
✔️ происходит пояснение выбора, обязательно высказываются участники, давшие самую высокую и низкую оценки
✔️ с учетом вышесказанного приходят к окончательной оценке пользовательской истории/эпика
📎 Пример: на моем проекте, где в работе над инициативой задействовано большое количество команд, две техники эстимации используются в комплексе. На первичном этапе для верхнеуровневой оценки объема работ над инициативой все команды оценивают эпики в размерах футболок. При этом относительные оценки в размерах футболок подразумевают не только время, трудозатраты, но и сложность. В дальнейшем, после успешной детализации эпиков в виде оформленных пользовательских историй, мы уже применяем традиционный числовой способ оценки в Story points.
Использование размеров футболок для оценки проектов
👉🏻 В руководстве по Scrum нет официального правила относительно того, как команда должна оценивать и измерять предстоящий объем работ. Можно использовать покер планирование, метод Дельфи, метод функциональных точек или диаграмму Ганта. В одной из статей мы уже рассмотрели наиболее популярную систему оценок задач в Story Points, которая отлично работает на практике.
☝🏻 На этот раз предлагаем вашему вниманию альтернативную технику - оценку задач в размерах футболки (маечную оценку или T-shirt sizes). Популярность данной техники обусловлена скоростью использования (за одну сессию можно оценить 10-15 историй), а также легкостью ее применения.
Для сравнения, при оценке в Story Points используется около 10 значений из последовательности Фибоначчи, это действительно много, и давать такой огромный выбор зачастую бессмысленно. Но все носят футболки, поэтому сотрудникам будет просто понять разницу между размером XS и L.
Использование этих размеров для оценки трудозатрат на инициативы команды — быстрый способ получить представление о том, сколько времени и сил потребуется на разработку без применения сложных расчетов. Посмотрим, как это работает:
👉🏻 В качестве единицы измерения используется размер футболки: S, M, L, XL (если крупный проект, то еще XXS, XS, XXL). При желании можно договориться о соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее. Команда принимает решение о размере пользовательской истории или функции в ходе совместной открытой дискуссии
🖍 Обычно первые несколько задач оцениваются предварительно или используется предыдущий опыт оценки задачи: определяются наименьшие относительно остальных задачи и принимаются за XS размер. После этого оставшиеся задачи оцениваются уже с точки зрения насколько они больше XS. В зависимости от этого им присваивается определенный размер: S, M, L и тд
Присвоение истории размера XXL свидетельствует о том, что на самом деле невозможно оценить задачу, т.к. она нуждается в дальнейшей декомпозиции и уточнении
Сам процесс оценки соответствует покер планированию:
✔️ владелец продукта представляет историю/эпик, дает краткое описание
✔️ участники команды задают вопросы и обсуждают, чтобы лучше ее понять
✔️ все участники одновременно дают свою оценку по данной задаче
✔️ происходит пояснение выбора, обязательно высказываются участники, давшие самую высокую и низкую оценки
✔️ с учетом вышесказанного приходят к окончательной оценке пользовательской истории/эпика
📎 Пример: на моем проекте, где в работе над инициативой задействовано большое количество команд, две техники эстимации используются в комплексе. На первичном этапе для верхнеуровневой оценки объема работ над инициативой все команды оценивают эпики в размерах футболок. При этом относительные оценки в размерах футболок подразумевают не только время, трудозатраты, но и сложность. В дальнейшем, после успешной детализации эпиков в виде оформленных пользовательских историй, мы уже применяем традиционный числовой способ оценки в Story points.
Нужно ли бизнес-аналитику уметь писать код❓
Статья размышление от системного аналитика Ерслана Аймакова.
❓ Один из весьма популярных вопросов у кандидатов на позиции IT-аналитика и у некоторых работодателей – должны ли они ожидать от такого сотрудника умения писать или хотя бы читать программный код на каком-либо языке программирования? По моему скромному мнению, короткий ответ – нет.
☝🏻 В этом месте каждая уважающая себя статья начинает новое предложение с громкого «НО!». Конечно же, умение писать и, соответственно, читать программный код никогда не будет лишним для любого IT-специалиста. Но давайте для начала все-таки разберем навыки, близкие к умению писать код, без которых хорошему аналитику все-же не обойтись:
👉🏻 Умение писать SQL-запросы. Основы искусства обращения к базам данных с помощью «языка» SQL – скилл, необходимый каждому аналитику, поскольку все мы так или иначе работаем с данными, хранимыми и обрабатываемыми посредством той или иной СУБД, и умение эти данные «вытаскивать» необходимо для решения большинства из каждодневных задач, стоящих перед аналитиком. Это еще не программирование, но уже солидный «хард-скилл», повышающий ваши конкурентные преимущества на рынке труда.
👉🏻 Знание API и умение работать с типами данных. На карьерном пути аналитика вам неизбежно придется столкнуться с интеграциями между информационными системами или модулями одной системы, а значит – работать с веб-сервисами – посредниками, передающими информацию от одной системы к другой с помощью сообщений, например, структурированных в виде популярных форматов JSON или XML.
Часто эта информация впоследствии должна быть помещена в базу данных. Сущности в сообщениях или полях базы представляют из себя набор полей, содержащих некие типизированные значения – например, если это числа – тип может быть целочисленным или с плавающей запятой, если это строка – она может иметь ограниченное количество символов, а может вам необходимо передать список из нескольких значений – и на это тоже есть свой тип данных.
В общем, если коротко – без знания типов и форматов данных, а также знание принципов работы API аналитику не обойтись. А обладая этими знаниями, вы можете считать, что находитесь на первом шаге изучения любого языка программирования!
👉🏻 Умение грамотно поставить задачу на разработку. Как аналитик, вы должны уметь поставить грамотную задачу на разработку – то есть, как минимум, расписать алгоритм работы вашей «фичи» - с чего должен начинаться процесс, какими должны быть входные и выходные данные, как должна обрабатываться информация.
Не так важно в каком формате вы это опишете, важно максимально прозрачно описать все шаги алгоритма, используя, к примеру, условия «Если – То – Иначе», описание обработки данных с помощью циклов, или «маппинг данных» - например, в какое поле базы данных мы должны поместить значение, полученное от сервиса-партнера.
➡️Если вы являетесь специалистом, которые умеет составить грамотную постановку задачи, считайте, что вы уже умеете программировать на базовом уровне – дело осталось за малым – начать изучать синтаксис того или иного языка!
📃 В заключение, хочется сказать, что любой опытный бизнес или системный аналитик уже близок к тому, чтобы усвоить какой-либо язык программирования. 💻Хорошим кандидатом для первого языка программирования является Python – изучив его, вы не только существенно повысите свою компетенцию в качестве БА/СА, но и можете продолжить свое развитие в сторону аналитика данных или специалиста в сфере машинного обучения.
Статья размышление от системного аналитика Ерслана Аймакова.
❓ Один из весьма популярных вопросов у кандидатов на позиции IT-аналитика и у некоторых работодателей – должны ли они ожидать от такого сотрудника умения писать или хотя бы читать программный код на каком-либо языке программирования? По моему скромному мнению, короткий ответ – нет.
☝🏻 В этом месте каждая уважающая себя статья начинает новое предложение с громкого «НО!». Конечно же, умение писать и, соответственно, читать программный код никогда не будет лишним для любого IT-специалиста. Но давайте для начала все-таки разберем навыки, близкие к умению писать код, без которых хорошему аналитику все-же не обойтись:
👉🏻 Умение писать SQL-запросы. Основы искусства обращения к базам данных с помощью «языка» SQL – скилл, необходимый каждому аналитику, поскольку все мы так или иначе работаем с данными, хранимыми и обрабатываемыми посредством той или иной СУБД, и умение эти данные «вытаскивать» необходимо для решения большинства из каждодневных задач, стоящих перед аналитиком. Это еще не программирование, но уже солидный «хард-скилл», повышающий ваши конкурентные преимущества на рынке труда.
👉🏻 Знание API и умение работать с типами данных. На карьерном пути аналитика вам неизбежно придется столкнуться с интеграциями между информационными системами или модулями одной системы, а значит – работать с веб-сервисами – посредниками, передающими информацию от одной системы к другой с помощью сообщений, например, структурированных в виде популярных форматов JSON или XML.
Часто эта информация впоследствии должна быть помещена в базу данных. Сущности в сообщениях или полях базы представляют из себя набор полей, содержащих некие типизированные значения – например, если это числа – тип может быть целочисленным или с плавающей запятой, если это строка – она может иметь ограниченное количество символов, а может вам необходимо передать список из нескольких значений – и на это тоже есть свой тип данных.
В общем, если коротко – без знания типов и форматов данных, а также знание принципов работы API аналитику не обойтись. А обладая этими знаниями, вы можете считать, что находитесь на первом шаге изучения любого языка программирования!
👉🏻 Умение грамотно поставить задачу на разработку. Как аналитик, вы должны уметь поставить грамотную задачу на разработку – то есть, как минимум, расписать алгоритм работы вашей «фичи» - с чего должен начинаться процесс, какими должны быть входные и выходные данные, как должна обрабатываться информация.
Не так важно в каком формате вы это опишете, важно максимально прозрачно описать все шаги алгоритма, используя, к примеру, условия «Если – То – Иначе», описание обработки данных с помощью циклов, или «маппинг данных» - например, в какое поле базы данных мы должны поместить значение, полученное от сервиса-партнера.
➡️Если вы являетесь специалистом, которые умеет составить грамотную постановку задачи, считайте, что вы уже умеете программировать на базовом уровне – дело осталось за малым – начать изучать синтаксис того или иного языка!
📃 В заключение, хочется сказать, что любой опытный бизнес или системный аналитик уже близок к тому, чтобы усвоить какой-либо язык программирования. 💻Хорошим кандидатом для первого языка программирования является Python – изучив его, вы не только существенно повысите свою компетенцию в качестве БА/СА, но и можете продолжить свое развитие в сторону аналитика данных или специалиста в сфере машинного обучения.
А как вы думаете, нужно ли бизнес аналитику знать языки программирования?
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
Как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.