Сегодня удивительный день в истории ИТ: День Рождения интернета🎉🎉🎉
🎈 29 октября 1969 года аспирант Калифорнийского университета в Лос-Анджелесе (UCLA) передал текст, состоящий из букв L-O, на удалённый компьютер двоих представителей Стэндфордского университета.
🎈 Двумя представителями Стэндфордского университета были Билл Дювалл и Чарли Клайн, а передаваемые буквы были началом слова «login», однако, компьютер принимающей стороны «завис», не дав закончить передачу всего слова. Позже их компьютеры были соединены с компьютерами в Университете штата Юта и Калифорнийском университете в Санта-Барбара, благодаря чему была создана сеть ARPANET (Сеть агентства передовых исследовательских проектов).
💻 Многие технические решения, порождённые этим прототипом, используются в глобальной сети по сей день.
💻 Так, многие существующие протоколы Интернета берут начало именно в ARPANET. Например, протокол обратного поиска DNS до сих пор использует доменное имя верхнего уровня «arpa»: чтобы найти записи, относящиеся к IP-адресу 1.2.3.4, надо послать запрос об адресе 4.3.2.1.in-addr.arpa. Основной протокол передачи данных сети Интернет — TCP/IP, тоже берёт начало в ARPANET.
🎈🎈🎈Так что, с Днем Рождения интернета!🎉🎉🎉
🎈 29 октября 1969 года аспирант Калифорнийского университета в Лос-Анджелесе (UCLA) передал текст, состоящий из букв L-O, на удалённый компьютер двоих представителей Стэндфордского университета.
🎈 Двумя представителями Стэндфордского университета были Билл Дювалл и Чарли Клайн, а передаваемые буквы были началом слова «login», однако, компьютер принимающей стороны «завис», не дав закончить передачу всего слова. Позже их компьютеры были соединены с компьютерами в Университете штата Юта и Калифорнийском университете в Санта-Барбара, благодаря чему была создана сеть ARPANET (Сеть агентства передовых исследовательских проектов).
💻 Многие технические решения, порождённые этим прототипом, используются в глобальной сети по сей день.
💻 Так, многие существующие протоколы Интернета берут начало именно в ARPANET. Например, протокол обратного поиска DNS до сих пор использует доменное имя верхнего уровня «arpa»: чтобы найти записи, относящиеся к IP-адресу 1.2.3.4, надо послать запрос об адресе 4.3.2.1.in-addr.arpa. Основной протокол передачи данных сети Интернет — TCP/IP, тоже берёт начало в ARPANET.
🎈🎈🎈Так что, с Днем Рождения интернета!🎉🎉🎉
Врываемся в ноябрь с Global Business Analyst Day!🎉
Всех бизнес-аналитиков с профессиональным праздником!💻🎈
Всех бизнес-аналитиков с профессиональным праздником!💻🎈
📃 Области рисков в бизнес анализе
Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».
Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.
Нас, в первую очередь, естественно, волнует негативный эффект, который могут принести риски. Давайте рассмотрим области рисков в бизнес — анализе.
1️⃣ Решения вместо потребностей
Вероятность того, что заинтересованные лица будут навязывать решения вместо потребностей, что повлечёт за собой разработку ненужного функционала, либо попросту трату времени на прояснение этих самых потребностей.
2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.
3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.
4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.
5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.
6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.
7️⃣ Непровалидированные, непроверифицированные требования.
🖍 Непровалидированные требования — требования, которые потенциально не отражают потребностей заинтересованных лиц, а значит потенциально направлены на разработку ненужного функционала.
🖍 Непроверифицированные требования — потенциально некачественные требования: неполные, некорректные и т. д. Отсутствие одного из качеств хорошо написанных требований может привести к ряду проблем.
👉🏻 Само собой, перечисленный в статье список не является избыточным. Риски могут крыться и в других областях, но главное для аналитика - вовремя их идентифицировать и вести работу с ними непрерывно.
Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».
Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.
Нас, в первую очередь, естественно, волнует негативный эффект, который могут принести риски. Давайте рассмотрим области рисков в бизнес — анализе.
1️⃣ Решения вместо потребностей
Вероятность того, что заинтересованные лица будут навязывать решения вместо потребностей, что повлечёт за собой разработку ненужного функционала, либо попросту трату времени на прояснение этих самых потребностей.
2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.
3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.
4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.
5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.
6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.
7️⃣ Непровалидированные, непроверифицированные требования.
🖍 Непровалидированные требования — требования, которые потенциально не отражают потребностей заинтересованных лиц, а значит потенциально направлены на разработку ненужного функционала.
🖍 Непроверифицированные требования — потенциально некачественные требования: неполные, некорректные и т. д. Отсутствие одного из качеств хорошо написанных требований может привести к ряду проблем.
👉🏻 Само собой, перечисленный в статье список не является избыточным. Риски могут крыться и в других областях, но главное для аналитика - вовремя их идентифицировать и вести работу с ними непрерывно.
Транзитные требования. Что это и как писать👇🏻
📍 Существуют случаи, когда предприятия внедряют новые ИТ решения как замену существующим. В тот промежуток времени, когда работают старое и новое решение, организации может потребоваться перемещать информацию между новой и старой системой, проводить обучение новому ПО для заинтересованных сторон и так далее.
Помимо разработки новой системы, разработчикам скорее всего придется имплементировать дополнительные решения, которые бы позволили осуществить и сам переход.
📍 Таким образом, транзитивные требования – это требования, которое должны выполняться в течение перехода организации от старой системы к новой. Срок действия этих требований - время переходного периода между решениями.
📍 В случае, если организация-заказчик планирует внедрить у себя новый ИТ продукт, который предоставляет совершенно новые возможности, а не является улучшением существующей системы, то транзитивные требования не анализируются, поскольку они и не существуют.
📌 В ходе написания транзитивных требований необходимо:
1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.
2️⃣ Определить готовность организации к внедрению новой системы. Может будет необходимо добавить новые возможности в организации в определенных сферах чтобы эксплуатация нового решения стала возможна.
3️⃣ Обозначить информацию и процессы, которые будут необходимы для заинтересованных сторон во время перехода.
4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.
5️⃣ Оценить текущие данные, чтобы определить, следует ли архивировать их или передать в новое решение. Кроме того, потребуется разработать правила преобразования этой информации и, возможно, определить бизнес-правила.
6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.
7️⃣ Может потребоваться разработать рекомендации по изменению организационной структуры предприятия или функций персонала, поскольку должностные обязанности могут значительно измениться в результате автоматизации работы.
📌 Полезные инструменты, используемые при сборе транзитивных требований:
👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.
👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.
👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.
📍 Существуют случаи, когда предприятия внедряют новые ИТ решения как замену существующим. В тот промежуток времени, когда работают старое и новое решение, организации может потребоваться перемещать информацию между новой и старой системой, проводить обучение новому ПО для заинтересованных сторон и так далее.
Помимо разработки новой системы, разработчикам скорее всего придется имплементировать дополнительные решения, которые бы позволили осуществить и сам переход.
📍 Таким образом, транзитивные требования – это требования, которое должны выполняться в течение перехода организации от старой системы к новой. Срок действия этих требований - время переходного периода между решениями.
📍 В случае, если организация-заказчик планирует внедрить у себя новый ИТ продукт, который предоставляет совершенно новые возможности, а не является улучшением существующей системы, то транзитивные требования не анализируются, поскольку они и не существуют.
📌 В ходе написания транзитивных требований необходимо:
1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.
2️⃣ Определить готовность организации к внедрению новой системы. Может будет необходимо добавить новые возможности в организации в определенных сферах чтобы эксплуатация нового решения стала возможна.
3️⃣ Обозначить информацию и процессы, которые будут необходимы для заинтересованных сторон во время перехода.
4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.
5️⃣ Оценить текущие данные, чтобы определить, следует ли архивировать их или передать в новое решение. Кроме того, потребуется разработать правила преобразования этой информации и, возможно, определить бизнес-правила.
6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.
7️⃣ Может потребоваться разработать рекомендации по изменению организационной структуры предприятия или функций персонала, поскольку должностные обязанности могут значительно измениться в результате автоматизации работы.
📌 Полезные инструменты, используемые при сборе транзитивных требований:
👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.
👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.
👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.
❗️ Вы системный аналитик? Тогда для вас новости!
👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"
👉🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"
👉🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
Друзья, всем привет!👋
Для тех, кто давно хотел начать карьеру в системной аналитике, стартует набор на бесплатный online-курс "System Analysis"😊.
Начало уже в декабре. Два месяца, два раза в неделю(три часа) вечером.
Вся информация в "шапке" регистрационной формы⬇️ https://forms.gle/fo4BrW9yvQVtp3T46
Для тех, кто давно хотел начать карьеру в системной аналитике, стартует набор на бесплатный online-курс "System Analysis"😊.
Начало уже в декабре. Два месяца, два раза в неделю(три часа) вечером.
Вся информация в "шапке" регистрационной формы⬇️ https://forms.gle/fo4BrW9yvQVtp3T46
Что такое Customer Journey Map и чем она полезна аналитику
👉 Карта путешествия клиента - Customer journey map (CJM) – это описание шагов, которые проходят пользователи при взаимодействии с компанией/продуктом, будь то онлайн-опыт, опыт розничной торговли, получение услуги или любая их комбинация.
Все пункты карты путешествия клиента принято называть точками контакта, они могут быть как онлайн так и оффлайн точками. Примеры онлайн точек: сайт, чат-бот, отзывы в Интернет, статьи, социальная сеть, онлайн-пощник, смс, мобильное приложение и др. Оффлайн точки контакта: консультант в магазине, каталог продукции, доставщик товара, сам товар, бизнес-процесс, реклама в печатных СМИ и др.
👉 В общем виде CJM – это таблица, иногда с элементами графического изображения. Не существуют унифицированного шаблона для CJM, однако можно выделить несколько основных элементов CJM:
1️⃣ Вертикальные столбцы. Имеют название этапов, проходимых клиентом. Например, если речь идет о покупке товара в интернет-магазине, то столбцы имели бы название желание приобрести, поиск, выбор, покупка, доставка, использование, лояльность.
2️⃣ Горизонтальные строки. Отражают характеристики для каждого этапа, т.е. как, когда, где и при каких условиях происходит взаимодействие. Например, для той же покупки в интернет-магазине, это были бы следующие строки: действия покупателя, цели покупателя, точки контакта, полученный опыт (эмоциональная оценка), проблемы, их решения, вовлеченные технические средства и т.д.
❗Особенности написания CJM:
📌 Количество как горизонтальных, так и вертикальных строк можно увеличивать или сокращать в зависимости от потребностей при описании CJM;
📌 Карта может разрабатываться для каждой пользовательской персоны, для персоны приносящей больше прибыли или для наиболее типичной персоны;
📌 Карта пригодна не только для более масштабного описания взаимодействия с продуктом выходящего за рамки посещения сайта (как в случае покупки товара онлайн), так и для описания более точечного взаимодействия (CJM покупки товара на самом сайте).
👉 CJM помогает:
📍систематизировать понимание о взаимодействии клиента с продуктом по разным каналам;
📍спрогнозировать поведение клиента в будущем;
📍при создании положительного UX (user experience) на всем протяжении использования продукта/услуги. Это непосредственно влияет на лояльность клиентов, т.е. приверженность к продукту и готовность вернуться к нему в будущем;
📍выявить и устранить барьеры при переходе от одной точки контакта к другой, тем самым доводя больше потребителей до цели.
👉 Карта путешествия клиента - Customer journey map (CJM) – это описание шагов, которые проходят пользователи при взаимодействии с компанией/продуктом, будь то онлайн-опыт, опыт розничной торговли, получение услуги или любая их комбинация.
Все пункты карты путешествия клиента принято называть точками контакта, они могут быть как онлайн так и оффлайн точками. Примеры онлайн точек: сайт, чат-бот, отзывы в Интернет, статьи, социальная сеть, онлайн-пощник, смс, мобильное приложение и др. Оффлайн точки контакта: консультант в магазине, каталог продукции, доставщик товара, сам товар, бизнес-процесс, реклама в печатных СМИ и др.
👉 В общем виде CJM – это таблица, иногда с элементами графического изображения. Не существуют унифицированного шаблона для CJM, однако можно выделить несколько основных элементов CJM:
1️⃣ Вертикальные столбцы. Имеют название этапов, проходимых клиентом. Например, если речь идет о покупке товара в интернет-магазине, то столбцы имели бы название желание приобрести, поиск, выбор, покупка, доставка, использование, лояльность.
2️⃣ Горизонтальные строки. Отражают характеристики для каждого этапа, т.е. как, когда, где и при каких условиях происходит взаимодействие. Например, для той же покупки в интернет-магазине, это были бы следующие строки: действия покупателя, цели покупателя, точки контакта, полученный опыт (эмоциональная оценка), проблемы, их решения, вовлеченные технические средства и т.д.
❗Особенности написания CJM:
📌 Количество как горизонтальных, так и вертикальных строк можно увеличивать или сокращать в зависимости от потребностей при описании CJM;
📌 Карта может разрабатываться для каждой пользовательской персоны, для персоны приносящей больше прибыли или для наиболее типичной персоны;
📌 Карта пригодна не только для более масштабного описания взаимодействия с продуктом выходящего за рамки посещения сайта (как в случае покупки товара онлайн), так и для описания более точечного взаимодействия (CJM покупки товара на самом сайте).
👉 CJM помогает:
📍систематизировать понимание о взаимодействии клиента с продуктом по разным каналам;
📍спрогнозировать поведение клиента в будущем;
📍при создании положительного UX (user experience) на всем протяжении использования продукта/услуги. Это непосредственно влияет на лояльность клиентов, т.е. приверженность к продукту и готовность вернуться к нему в будущем;
📍выявить и устранить барьеры при переходе от одной точки контакта к другой, тем самым доводя больше потребителей до цели.
Приятная новость😉 Ведущий BA из Andersen - Виталий Бирченко - выступит на ANALYST DAYS!
Тринадцатая Международная Конференция, посвященная системному и бизнес анализу, пройдет в Москве 19-20 ноября. Спикер из Andersen поделится своим опытом и выступит 19 ноября с докладом: “BA vs SME. Взаимодействие вместо противостояния”. Разбор темы на реальных Healthcare кейсах будет интересен как аналитикам, так и экспертам.
Желаем Виталию классно выступить💪
👉 Познакомиться со всей программой ANALYST DAY/13 и купить на него билеты можно по ссылке👇
https://analystdays.ru/ru/index
Тринадцатая Международная Конференция, посвященная системному и бизнес анализу, пройдет в Москве 19-20 ноября. Спикер из Andersen поделится своим опытом и выступит 19 ноября с докладом: “BA vs SME. Взаимодействие вместо противостояния”. Разбор темы на реальных Healthcare кейсах будет интересен как аналитикам, так и экспертам.
Желаем Виталию классно выступить💪
👉 Познакомиться со всей программой ANALYST DAY/13 и купить на него билеты можно по ссылке👇
https://analystdays.ru/ru/index
Всем замечательного понедельника! 🔆
Сегодня поговорим о системном анализе, а именно об объектах и методах интеграции.☝🏻💻
➡️ Объект интеграции - компонент интегрируемых информационных систем. Объектами интеграции могут выступать:
📍 платформы (ОС Windows, ОС Linux, сервер Intel Xeon и т.п.);
📍 данные (БД, СУБД Oracle Database, Microsoft SQL Server и т.п.);
📍 приложения (сервер приложений Microsoft, Java Runtine Environment, бизнес-логика или интерфейс какого-то приложения и т.п.);
📍 бизнес-процессы (функции сотрудников).
👉🏻 Интеграция платформ - это установление взаимодействия между приложениями, работающими на различных платформах (например, между приложениями на Linux и Windows), а также обеспечение работы приложений, разработанных для одной платформы, на других платформах (например, приложений Windows на платформе Solaris).
➡️ Интеграция платформ осуществляется следующими методами:
📍 Удаленный вызов процедур (remote procedure call RPC, Web-сервисы, REST и др.);
📍 ПО промежуточного слоя (Microsoft.Net, Java Runtime);
📍 Виртуализация - технология программного представления виртуальной версии ИТ-продуктов.
Интеграция данных предполагает совместное использование данных различных систем.
Осуществляется следующими методами:
📍 Универсальный доступ к данным - например, есть две БД, мы интегрируем одну со второй так, что первая получает всю необходимую информацию со второй по средствам запросов на выборку данных;
📍 Хранилища данных – информация с нескольких информационных систем «сливатся» в единое пространство (Data Lake).
Интеграция приложений – это использование функций одних приложений другими приложениями. Осуществляется следующими методами:
📍Интерфейсы прикладного программирования (API) - набор функций, который программист может использовать для доступа к данным и алгоритмам программ;
📍 Обмен сообщениями (Корпоративная сервисная шина) – промежуточный программный стой между приложениями, на котором происходит хранение актуальных данных и их обмен со всеми интегрируемыми приложениями;
📍 Сервис-ориентированная архитектура (SOA) – модульный подход к разработке ПО, базирующийся на использовании сервисов;
📍Интеграция пользовательских интерфейсов – интеграции UI компонентов за счет объединения их внешнего представления, а не логики или схем данных самих приложений.
Интеграция бизнес-процессов - это интеграция приложений, данных и людей, вовлеченных в определенный бизнес-процесс. Здесь речь больше идет о функциях сотрудников, не о программной среде. Например, слияние ролей менеджера по приему заказов с частью функций менеджера по поиску клиентов.
Сегодня поговорим о системном анализе, а именно об объектах и методах интеграции.☝🏻💻
➡️ Объект интеграции - компонент интегрируемых информационных систем. Объектами интеграции могут выступать:
📍 платформы (ОС Windows, ОС Linux, сервер Intel Xeon и т.п.);
📍 данные (БД, СУБД Oracle Database, Microsoft SQL Server и т.п.);
📍 приложения (сервер приложений Microsoft, Java Runtine Environment, бизнес-логика или интерфейс какого-то приложения и т.п.);
📍 бизнес-процессы (функции сотрудников).
👉🏻 Интеграция платформ - это установление взаимодействия между приложениями, работающими на различных платформах (например, между приложениями на Linux и Windows), а также обеспечение работы приложений, разработанных для одной платформы, на других платформах (например, приложений Windows на платформе Solaris).
➡️ Интеграция платформ осуществляется следующими методами:
📍 Удаленный вызов процедур (remote procedure call RPC, Web-сервисы, REST и др.);
📍 ПО промежуточного слоя (Microsoft.Net, Java Runtime);
📍 Виртуализация - технология программного представления виртуальной версии ИТ-продуктов.
Интеграция данных предполагает совместное использование данных различных систем.
Осуществляется следующими методами:
📍 Универсальный доступ к данным - например, есть две БД, мы интегрируем одну со второй так, что первая получает всю необходимую информацию со второй по средствам запросов на выборку данных;
📍 Хранилища данных – информация с нескольких информационных систем «сливатся» в единое пространство (Data Lake).
Интеграция приложений – это использование функций одних приложений другими приложениями. Осуществляется следующими методами:
📍Интерфейсы прикладного программирования (API) - набор функций, который программист может использовать для доступа к данным и алгоритмам программ;
📍 Обмен сообщениями (Корпоративная сервисная шина) – промежуточный программный стой между приложениями, на котором происходит хранение актуальных данных и их обмен со всеми интегрируемыми приложениями;
📍 Сервис-ориентированная архитектура (SOA) – модульный подход к разработке ПО, базирующийся на использовании сервисов;
📍Интеграция пользовательских интерфейсов – интеграции UI компонентов за счет объединения их внешнего представления, а не логики или схем данных самих приложений.
Интеграция бизнес-процессов - это интеграция приложений, данных и людей, вовлеченных в определенный бизнес-процесс. Здесь речь больше идет о функциях сотрудников, не о программной среде. Например, слияние ролей менеджера по приему заказов с частью функций менеджера по поиску клиентов.
⭐️ Напоминаем, что остались последние деньки стать системным аналитиком в компании Andersen и получить хороший sign-on bonus💰💰
Программа "SA hiring days! Получи Job Offer в 3 шага!" заканчивается уже 30ого ноября.
☝🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
Программа "SA hiring days! Получи Job Offer в 3 шага!" заканчивается уже 30ого ноября.
☝🏻 Какие этапы?
1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/
2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)
3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!
📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/
Техники выявления рисков.
👉🏻 Согласно PMBOK (Project Management Body of Knowledge – своду знаний по управлению проектами) риск – это неопределенное событие или условие, которое может как положительно, так и отрицательно повлиять на результаты и цели проекта.
Чтобы минимизировать негативные последствия и увеличить позитивные, так важен процесс управления требованиями. Он начинается с их выявления и сейчас мы расскажем о некоторых из них:
📍 Анализ информации - подвергайте критическому анализу всю документацию, в том числе данные, которые заказчик представляет как “точно верные”. Зачастую там можно найти двусмысленности и неясности, которые позже могут оказать влияние на продукт и стать рисками. Плохие требования - главная причина неудач проекта.
📍 Анализ категорий рисков для выявления типичных рисков - открываем список видов рисков по Вигерсу и(или) BABOK и выбираем типы рисков, наиболее релевантных для нашего проекта.
📍 Анализ предположений и зависимостей - по своей природе они сопряжены с риском. Регулярно просматривайте и проверяйте предположения и зависимости.
📍 Мозговой штурм – собираем все, даже самые глупые и маловероятные идеи рисков на нашем проекте, а затем из полученных вариантов выбираем наиболее релевантные.
📍 Личный опыт – выявленные на прошлых проектах риски часто можно переиспользовать, а их повторная идентификация в будущем происходит проще и быстрее. Но не все риски можно переиспользовать - избегайте эффекта золотого молотка☺️
📍 Мнение и опыт экспертов (внешние эксперты, коллеги, авторитетные источники в интернете и т.д.) - эта техника может сыграть решающее значение, если Вы новичок в домене проекта или только начинаете карьеры. Не стесняйтесь спрашивать Ваших коллег (особенно в Andersen Вам всегда придут на помощь:)
➡️ Помните, что идентификация рисков - постоянный процесс на любой стадии проекта, поэтому список рисков нужно регулярно обновлять и помнить, что их идентификация - только первый шаг в процессе управления рисками. После идентификации рисков мы вносим их в реестр рисков.
📃 Реестр рисков — это инструмент, используемый для отслеживания и мониторинга проектных рисков. Подробнее о нем мы мы расскажем в следующем посте.
👉🏻 Согласно PMBOK (Project Management Body of Knowledge – своду знаний по управлению проектами) риск – это неопределенное событие или условие, которое может как положительно, так и отрицательно повлиять на результаты и цели проекта.
Чтобы минимизировать негативные последствия и увеличить позитивные, так важен процесс управления требованиями. Он начинается с их выявления и сейчас мы расскажем о некоторых из них:
📍 Анализ информации - подвергайте критическому анализу всю документацию, в том числе данные, которые заказчик представляет как “точно верные”. Зачастую там можно найти двусмысленности и неясности, которые позже могут оказать влияние на продукт и стать рисками. Плохие требования - главная причина неудач проекта.
📍 Анализ категорий рисков для выявления типичных рисков - открываем список видов рисков по Вигерсу и(или) BABOK и выбираем типы рисков, наиболее релевантных для нашего проекта.
📍 Анализ предположений и зависимостей - по своей природе они сопряжены с риском. Регулярно просматривайте и проверяйте предположения и зависимости.
📍 Мозговой штурм – собираем все, даже самые глупые и маловероятные идеи рисков на нашем проекте, а затем из полученных вариантов выбираем наиболее релевантные.
📍 Личный опыт – выявленные на прошлых проектах риски часто можно переиспользовать, а их повторная идентификация в будущем происходит проще и быстрее. Но не все риски можно переиспользовать - избегайте эффекта золотого молотка☺️
📍 Мнение и опыт экспертов (внешние эксперты, коллеги, авторитетные источники в интернете и т.д.) - эта техника может сыграть решающее значение, если Вы новичок в домене проекта или только начинаете карьеры. Не стесняйтесь спрашивать Ваших коллег (особенно в Andersen Вам всегда придут на помощь:)
➡️ Помните, что идентификация рисков - постоянный процесс на любой стадии проекта, поэтому список рисков нужно регулярно обновлять и помнить, что их идентификация - только первый шаг в процессе управления рисками. После идентификации рисков мы вносим их в реестр рисков.
📃 Реестр рисков — это инструмент, используемый для отслеживания и мониторинга проектных рисков. Подробнее о нем мы мы расскажем в следующем посте.
Продолжаем тему рисков и сегодня поговорим о реестре рисков.
📃 Реестр рисков на проекте. Что это и как создать.
👉🏻 Очевидно, что недостаточно просто знать о существовании рисков. Крайне важно работать с ними постоянно пока идет разработка. Это нужно для того, чтобы вовремя узнать о проблеме и сообщить о ней Заказчику и заинтересованным лицам. Помимо того, что риск может привести к потерям на проекте, он также может поставить под угрозу успех проекта в целом. Поэтому очень важным этапом в работе аналитика становится диагностика рисков.
Основной целью диагностики рисков являются актуализация и систематизация потенциальных рисков, а самое главное, создание и ведение Реестра рисков.
Результатом же диагностики рисков является создание условий для качественного и количественного измерения рисков.
При идентификации риска осуществляется анализ всех возможных факторов, объектов риска. Результатом выявления и анализа рисков является Реестр рисков. Иными словами, Реестр рисков это документ, содержащий все риски проекта с описанием и планами по работе с ними.
👉🏻 Как правило, риск описанный в документе включает следующие аспекты :
📌 Идентификационный номер риска;
Уникальный идентификатор должен быть присвоен каждому риску в момент обнаружения;
📌 Дата открытия риска;
Когда риск был обнаружен.
📌 Дата закрытия риска;
Когда риск был закрыт.
📌 Описание риска;
Обратимся к К. Вигерсу: «...сначала формулируйте причину возникновения риска, вызывающую озабоченность, а затем ее возможный неблагоприятный результат — следствие. Часто люди, говорящие о риске, приводят только условие («клиенты не придут к единому мнению относительно требований к продукту») или только следствие («мы сможем удовлетворить лишь одного из наших основных клиентов»).
📌 Убытки/потери;
В этом разделе следует описать все области проекта, которые буду затронуты при наступлении риска;
📌 Вероятность наступления;
Стандартно используется шкала
➡️ Высокие риски — это риски, для которых характерна высокая частота наступления ущерба.
➡️ Средние риски — это риски, для которых характерна средняя частота нанесения ущерба.
➡️ Низкие риски — это риски, для которых характерна малая вероятность наступления ущерба.
📌 План по работе с риском;
В этот раздел включаем действия, которые будем предпринимать по работе с риском.
📌Автор риска.
Не забывайте, управление рисками-ваш друг!
📃 Реестр рисков на проекте. Что это и как создать.
👉🏻 Очевидно, что недостаточно просто знать о существовании рисков. Крайне важно работать с ними постоянно пока идет разработка. Это нужно для того, чтобы вовремя узнать о проблеме и сообщить о ней Заказчику и заинтересованным лицам. Помимо того, что риск может привести к потерям на проекте, он также может поставить под угрозу успех проекта в целом. Поэтому очень важным этапом в работе аналитика становится диагностика рисков.
Основной целью диагностики рисков являются актуализация и систематизация потенциальных рисков, а самое главное, создание и ведение Реестра рисков.
Результатом же диагностики рисков является создание условий для качественного и количественного измерения рисков.
При идентификации риска осуществляется анализ всех возможных факторов, объектов риска. Результатом выявления и анализа рисков является Реестр рисков. Иными словами, Реестр рисков это документ, содержащий все риски проекта с описанием и планами по работе с ними.
👉🏻 Как правило, риск описанный в документе включает следующие аспекты :
📌 Идентификационный номер риска;
Уникальный идентификатор должен быть присвоен каждому риску в момент обнаружения;
📌 Дата открытия риска;
Когда риск был обнаружен.
📌 Дата закрытия риска;
Когда риск был закрыт.
📌 Описание риска;
Обратимся к К. Вигерсу: «...сначала формулируйте причину возникновения риска, вызывающую озабоченность, а затем ее возможный неблагоприятный результат — следствие. Часто люди, говорящие о риске, приводят только условие («клиенты не придут к единому мнению относительно требований к продукту») или только следствие («мы сможем удовлетворить лишь одного из наших основных клиентов»).
📌 Убытки/потери;
В этом разделе следует описать все области проекта, которые буду затронуты при наступлении риска;
📌 Вероятность наступления;
Стандартно используется шкала
➡️ Высокие риски — это риски, для которых характерна высокая частота наступления ущерба.
➡️ Средние риски — это риски, для которых характерна средняя частота нанесения ущерба.
➡️ Низкие риски — это риски, для которых характерна малая вероятность наступления ущерба.
📌 План по работе с риском;
В этот раздел включаем действия, которые будем предпринимать по работе с риском.
📌Автор риска.
Не забывайте, управление рисками-ваш друг!
Гендерно-нейтральные местоимения в английском языке при написании требований.
☝🏻 Скорее всего, вы не раз задумывались над вопросом, какие же местоимения использоваться в документации, чтобы избежать неполиткорректных смысловых конструкций. Сегодня поговорим об использовании гендерно нейтральных местоимений или вариантах их замещения при созданий требований.
1️⃣ Вариант первый. "THEY"
С точки зрения современного английского языка приемлемым вариантом будет использование местоимения 👉🏻 “THEY” и его производных, когда мы говорим, например, о пользователе в единственном числе.
Это нам позволяют делать заслуживающие доверия словари английского языка, в которых говорится o “they” следующее:
👉🏻 pronoun (PERSON)
📍 used to refer to a person when you want to avoid saying 'he' or 'she' or when you do not know if the person is male or female (Cambridge dictionary)
📍 used instead of he or she to refer to a person whose sex is not mentioned or not known (Oxford dictionary)
📍 used with a singular antecedent to refer to an unknown or unspecified person
The person who answered the phone said they didn't know where she was
📍 used to refer to a single person whose gender is intentionally not revealed (Merriam-Webster dictionary)
В этом варианте требование будет выглядеть так.
A user enters their login and password to access the system.
Вместе с тем вариант с гендерно-нейтральным местоимением “they” следует использовать, если вы уверены в отсутствии негативного отклика со стороны читателя.
2️⃣ Вариант второй.
Для тех, кто чтит старые устои и не готов к таким радикальным переменам в языке, тоже есть вариант - при упоминании пользователя использовать множественное число.
The users enter their logins and passwords to access the system.
3️⃣ Вариант третий.
Этот вариант является наиболее правильным и вместе с тем требующим иногда чуть больше времени для написания требований.
Он заключается в том, чтобы строить предложение таким образом, чтобы отсутствовала необходимость в использовании местоимений.
A user enters personal login and password to access the system.
☝🏻 И немного истории.
В различные периоды могли использоваться варианты с одновременным перечислением “she” and “he” или “s/he”, или даже “ze”. Но они не прижились, т.к усложняли восприятие.
☝🏻 Скорее всего, вы не раз задумывались над вопросом, какие же местоимения использоваться в документации, чтобы избежать неполиткорректных смысловых конструкций. Сегодня поговорим об использовании гендерно нейтральных местоимений или вариантах их замещения при созданий требований.
1️⃣ Вариант первый. "THEY"
С точки зрения современного английского языка приемлемым вариантом будет использование местоимения 👉🏻 “THEY” и его производных, когда мы говорим, например, о пользователе в единственном числе.
Это нам позволяют делать заслуживающие доверия словари английского языка, в которых говорится o “they” следующее:
👉🏻 pronoun (PERSON)
📍 used to refer to a person when you want to avoid saying 'he' or 'she' or when you do not know if the person is male or female (Cambridge dictionary)
📍 used instead of he or she to refer to a person whose sex is not mentioned or not known (Oxford dictionary)
📍 used with a singular antecedent to refer to an unknown or unspecified person
The person who answered the phone said they didn't know where she was
📍 used to refer to a single person whose gender is intentionally not revealed (Merriam-Webster dictionary)
В этом варианте требование будет выглядеть так.
A user enters their login and password to access the system.
Вместе с тем вариант с гендерно-нейтральным местоимением “they” следует использовать, если вы уверены в отсутствии негативного отклика со стороны читателя.
2️⃣ Вариант второй.
Для тех, кто чтит старые устои и не готов к таким радикальным переменам в языке, тоже есть вариант - при упоминании пользователя использовать множественное число.
The users enter their logins and passwords to access the system.
3️⃣ Вариант третий.
Этот вариант является наиболее правильным и вместе с тем требующим иногда чуть больше времени для написания требований.
Он заключается в том, чтобы строить предложение таким образом, чтобы отсутствовала необходимость в использовании местоимений.
A user enters personal login and password to access the system.
☝🏻 И немного истории.
В различные периоды могли использоваться варианты с одновременным перечислением “she” and “he” или “s/he”, или даже “ze”. Но они не прижились, т.к усложняли восприятие.
А какие вы используете гендерные местоимения при написании требований?
Anonymous Poll
7%
"He" или "She"
19%
"They"
43%
Стараюсь вообще избегать, использую только "user'
4%
Всегда пишу по-разному
28%
Не пишу/Еще не писал(а) требования на английском языке
Как системному аналитику выбрать крутой проект и не прогадать?
В статье автор, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка, рассказала о:
⁃ как senior или middle аналитику удачно выбрать проект;
⁃ какое будущее на рынке системного анализа;
⁃ с какими проблемами сталкиваются системные аналитики на проектах чаще всего.
https://habr.com/ru/company/rshb/blog/592951/
В статье автор, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка, рассказала о:
⁃ как senior или middle аналитику удачно выбрать проект;
⁃ какое будущее на рынке системного анализа;
⁃ с какими проблемами сталкиваются системные аналитики на проектах чаще всего.
https://habr.com/ru/company/rshb/blog/592951/
Хабр
Как системному аналитику выбрать крутой проект и не прогадать?
Сейчас рынок системного анализа переживает бурный рост и на это есть несколько причин: низкий порог входа (по сравнению с Java-разработчиками, например) несколько хаотичные требования к...