Маечная система оценок👕. Что это и как
Использование размеров футболок для оценки проектов
👉🏻 В руководстве по 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
Как правильно определять требования к продукту или системе, чтобы результаты разработки совпадали с ожиданиями.
Отличия 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/