Что такое кейс программы

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

Сценарии использования- это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Цель: моделирование и проектирование взаимодействия пользователя с системой в рамках выполнения одного сценария. Пошаговое подробное взаимодействие пользователя с системой.

Документирование: таблица с описанием действий актора и реагирование системы на определенные шаги пользователя.

Один сценарий использования имеет несколько потоков: основной и альтернативные.

Выделение сценариев

Один сценарий использования должен описывать действия пользователя, которые приведут к одному большому действию- функционалу пользователя. Например, авторизоваться, добавить товар в корзину и тд.

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

Что такое кейс для политического убежища в Америке / Как написать историю

Каждый основной сценарий использования должен быть независимым от другого основного. Если есть определенные условия выполнения- указываем в “Предусловия”

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

Уровни описания и степени детализации

Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.

1. Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей. Деловой сценарий использования описывает процесс, ценный для клиента, описывает что именно делает процесс.
2. Системный сценарий использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер)

Степень формализма выполняемого проекта и стадия, на которой он находится, прямо влияют на степень детальности и проработанности вариантов использования. Определяют следующие степени детальности при написании вариантов использования:

1. Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.

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

Значение слова кейс. Что такое кейс.

1. Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

Детальный уровень описания применяют при написании ТЗ. Преимущественно, при написании ТЗ все кейсы необходимо описывать на детальной степени; обязательно применять детальную степень и системный уровень при описании кейсов с высоким уровнем риска.

Структура сценария использования

Сценарии использования включают в себя следующие разделы:

1. Название. Краткое, максимально понятное. Описывающее общее действие пользователя.

UC-1. Регистрация в личном кабинете

UC-2. Регистрация в программе лояльности

UC-3. Добавление товара в корзину

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

Пример: пользователь находится в “Корзине”, в “Корзине” добавлено 2 товара”.

Данное предусловие мы можем указать для описания кейса работы пользователя в “Корзине”. Если мы описываем кейс “Добавление товара в корзину” или “Оформление заказа”, где необходимо указать всю цепочку шагов пользователя- то данное предусловие не подойдет.

1. Основной сценарий. Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.
2. Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Сценарий использования должен отвечать на вопрос “Что делает пользователь?” “Что делает система?”

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

Например, формулировка “добавил товар в корзину” неверная.

Правильно: “нажимает на кнопку “Добавить товар в корзину” и далее- реакцию системы на действия пользователя.

Пользователь

Система

Какое физическое действие произвел пользователь?

Как отреагировала система?

Нажимает “Добавить в корзину”

Система добавляет выбранный товар в корзину. В иконке “Корзина” система выводит маркер- кол-во добавленного товара в корзину.

Изменяет кнопку “Добавить в корзину” у выбранного товара на кнопку “Перейти в корзину”

Пользователь нажимает “перейти в корзину”

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

Альтернативные сценарии

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

Важно! Альтернативный сценарий должен ссылаться только на один успешный сценарий. Недопустимо прописывать альтернативный сценарий для альтернативного сценария.

Рассмотрим на примере авторизации

Предусловие: неавторизованный пользователь находится на странице авторизации и регистрации

Пользователь

Система

Какое физическое действие произвел пользователь?

Как отреагировала система?

Пользователь нажал кнопку “Зарегистрироваться”

Система вывела форму регистрации, поле “email”

Пользователь вводит данные в поле “email”

3. Система производит проверку введенных данных на валидацию. Данные проходят по условиям валидации

Если данные не прошли проверку валидации, запускается альтернативный сценарий №1.

Система производит поиск введенных данных “email” по учетным записям в системе.

Учетных записей с такими данными “email” не найдено.

Если в системе найдена учетная запись с таким логином, запускается альтернативный сценарий №2

Система отправляет пользователю код подтверждения на email

Система выводит пользователю поле “код подтверждения”

Сценарий “ввод кода подтверждения” вынесен в отдельный сценарий. — обязательно указываем, если какой-либо функционал выносим в отдельный кейс, более подробный.

Пользователь вводит корректный код подтверждения в поле “код подтверждения”

Система производит проверку кода подтверждения. Код введен верно.

Альтернативный сценарий с неверным кодом подтверждения выносим в сценарий “Ввод кода подтверждения”

Пример альтернативного сценария

Альтернативный сценарий №1

На шаге №3 успешного сценария, введенные данные не прошли проверку валидации.

1. Система выводит информер с указанием запрещенных символов.
2. Пользователь вводит корректные данные в поле “email”.

Далее сценарий продолжается от шага №3 успешного сценария.

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

• сценарии использования
• use case

Источник: habr.com

CASE-система

CASE (Computer Aided Software Engineering) — средства разработки программных и организационно-управляющих систем. Они охватывают большую часть поддержки огромного числа технологий проектирования КИС: начиная с простых средств анализа и документирования и заканчивая масштабными средствами автоматизации, охватывающими весь жизненный цикл программного обеспечения.

Назначение CASE-систем

Окно программы EasyCase в среде Windows.

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

• объединение определенных компонентов CASE-средств, которое дает возможность управляемость процессом разработки информационных систем;
• репозитория;
• наличие графических средств, с помощью которых можно описывать и документировать информационные системы, которые предоставят удобный интерфейс с разработчиком;

Компонентная база CASE-системы

В состав интегрированного CASE-средства входят следующие элементы:

• репозиторий — главное CASE-средство. Его задача — обеспечить сохранность вариантов проекта и его определенных компонентов, синхронизацию приема информации от разных разработчиков в процессе групповой разработки, проверка метаданных на полноту и непротиворечивость;
• средства разработки приложений, с использованием языков 4GL и генераторов кодов;
• средства тестирования;
• средства документирования;
• графические средства анализа и проектирования, которые дают возможность создавать и редактировать иерархически связанные диаграммы (например, DFD, ER-диаграмма и др.), создающие модели информационных систем;
• средства реинжиниринга.
• средства конфигурационного управления;
• средства управления проектом.

Классификация

В настоящее время существует классификация CASE-средств по следующим признакам:

• по типам — данная классификация демонстрирует функциональную ориентацию CASE-средств на какие-либо процессы жизненного цикла;
• по категориям – такая квалификация определяет уровень интегрированности по выполняемым функциям. Сюда относятся отдельные локальные средства, которые решают мелкие автономные задачи, комплект частично интегрированных средств, который затрагивает большую часть этапов жизненного цикла информационных систем. Также включает в себя полностью интегрированные средства, которые поддерживают весь жизненный цикл информационных систем и связанны общим репозиторием;
• по степени интегрированности с СУБД;
• по доступным платформам;
• по применяемым методологиям и моделям систем и БД.

Типовая классификация практически полностью совпадает с элементами, входящими в состав CASE-средств и состоит из следующих типов:

• верхние CASE–системы (Upper CASE) — средства анализа, которые используются для построения и анализа моделей предметной области ( BPwin (Logic Works)). В связи с тем, что эти системы соответствуют основным понятиям термина CASE, их также называют нормальными;
• средние CASE–системы (Middle CASE) — средства анализа и проектирования, корорые придерживаются более распространенные методологии проектирования и используются для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (Oracle), Silverrun (CSA)). Выход этих средств — спецификация архитектуры системы, составляющих и интерфейсов системы, алгоритмов и устройств данных;
• средства разработки приложений (PowerBuilder (Sybase), JAM (JYACC), Developer/2000 (Oracle), New Era (Informix Software) , Delphi (Borland), средства 4GL (Uniface (Compuware), SQLWindows (Gupta), а также генераторы кодов, которые входят в состав Vantage Team Builder, PRO-IV и отчасти в Silverrun;
• средства реинжиниринга, предназначенные для анализа программных кодов и схем баз данных и создания на их базе различного рода моделей и проектных спецификаций. Средства анализа схем баз данных и формирования ER-диаграмм являются составляющими Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В сфере анализа программных кодов наиболее широко распространены объектно-ориентированные CASE-средства, способствующие реинжинирингу программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)).
• средства проектирования баз данных, предоставляющие возможность моделировать данные и генерировать схемы баз данных, как правило, на языке SQL, для самых распространенных систем управления базами данных (например, ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE);

В состав вспомогательных типов входят средства планирования и управления проектом (SE Companion, Microsoft Project и др.), средства конфигурационного управления (PVCS (Intersolv));

• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).

Существующие CASE-системы

• ERwin+BPwin
• Designer/2000
• Silverrun
• S-Designor
• Vantage Team Builder
• Westmount I-CASE
• CASE.Аналитик
• PRO-IV
• CASE /4/0, System Architect
• EasyCASE,
• Visible Analyst Workbench

Ссылки

• Что такоеCASE-система
• CASE: все только начинаетсяМоделированиеИнформационные технологии
• Назначение и разновидности CASE-систем
• Современные средства разработки, CASE-системы
• citforum.ru: CASE-технологии

Источник: www.tadviser.ru

Введение в кейс-метод: что такое кейсы и зачем они нужны

Кейс (от англ. сase) — это описание конкретной ситуации или случая в какой-либо сфере: социальной, экономической, медицинской и т. д. Как правило, кейс содержит не просто описание, но и некую проблему или противоречие и строится на реальных фактах.

Соответственно, решить кейс — это значит проанализировать предложенную ситуацию и найти оптимальное решение. Врач решает кейсы каждый раз, когда ставит пациенту диагноз и назначает лечение. Юрист решает кейс, разбираясь в перипетиях дела и предлагая клиенту наилучший выход. Менеджер решает кейсы на всех этапах бизнес-процесса: какой продукт запустить, где его продавать, как привлечь покупателей, каких поставщиков и партнеров выбрать.

Сравнительно недавно началось активное использование кейс-технологии в образовании и сейчас этот подход стал одной из самых эффективных технологий обучения. В чем преимущества кейс-метода по сравнению с традиционными методами обучения? Назовем три самых главных:

• Практическая направленность. Кейс-метод позволяет применить теоретические знания к решению практических задач. Такой подход компенсирует исключительно академическое образование и дает более широкое представление о бизнесе и процессах, нежели лекции в вузе или практика на узком участке работ.
• Интерактивный формат. Кейс-метод обеспечивает более эффективное усвоение материала за счет высокой эмоциональной вовлеченности и активного участия обучаемых. Участники погружаются в ситуацию с головой: у кейса есть главный герой, на место которого ставит себя команда и решает проблему от его лица. Акцент при обучении делается не на овладевание готовым знанием, а на его выработку.
• Конкретные навыки. Кейс-метод позволяет совершенствовать «мягкие навыки» (soft skills), которым не учат в университете, но которые оказываются крайне необходимы в реальном рабочем процессе.

Совместный разбор жизненных ситуаций — универсальный способ обучения, поэтому аналоги решения кейсов можно найти еще в античности. Спартанские юноши разбирали со своими наставниками ситуации, возникающие на поле боя, а обсуждение «случаев» со своими учениками было излюбленным методом Сократа.

В современном виде кейс-метод зародился в 1870-е годы в Гарвардской школе права, а в бизнес-обучении утвердился с 1920-х годов. Преподаватели первых программ МВА были учеными, а не бизнесменами, и они столкнулись с тем, что невозможно было обучить студентов ведению бизнеса исключительно при помощи лекций и учебников.

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

Профессор HBS Крис Кристен сен (Chris Christensen) написал сотни кейсов и считается чемпионом по обучению кейс-методу

Отличительные особенности кейс-метода

Решение кейсов состоит из нескольких шагов:

1) исследования предложенной ситуации (кейса);

2) сбора и анализа недостающей информации;

3) обсуждения возможных вариантов решения проблемы;

4) выработки наилучшего решения.

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

Во-первых, кейс не имеет правильного ответа. Оптимальное решение может быть одно (при этом оно не всегда может быть реализовано в реальной ситуации), а вот эффективных решений — несколько.

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

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

Как пишутся кейсы

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

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

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

Качественный кейс должен объединять в себе пять ключевых аспектов:

Кейсы различаются по формату использования и уровню сложности.

По формату использования выделяют:

• Executive-кейсы (1–2 стр. и менее). Участники знакомятся с кейсом непосредственно на мероприятии и решают его индивидуально или в формате обсуждения с модератором. Такие кейсы используются в качестве иллюстрации теоретического материала или для проверки конкретных узких навыков.
• Тематические кейсы (3–5 стр.). Предназначены для разбора на учебном занятии и общей дискуссии, иногда предполагается краткая предварительная подготовка участников.
• Гарвардские кейсы (в среднем 20–25 стр.). Подразумевают самостоятельную командную работу в течение нескольких дней и презентацию решения.

По уровню сложности кейсы могут быть:

• Структурированными (highly structured). Включают в себя минимальное количество дополнительной информации. В них заложена определенная модель решения, и существует оптимальный вариант решения.
• «Маленькими набросками» (short vignetts). Знакомят только с ключевыми понятиями, включают 2–3 стр. приложений. Участникам требуются дополнительные знания для работы.
• Большими неструктурированными (long unstructured cases). Это самые сложные кейсы. Участникам нужно справиться с большим объемом слабо структурированных данных. В кейс может включаться лишняя информация и/или отсутствовать необходимые данные.

Структура классического (гарвардского) кейса

Использование кейс-метода в образовании на примере зарубежных школ

Метод case-study впервые стали использоваться при обучении в Гарварде (США), и с тех пор Гарвард во многом определяет формат кейс-образования во всем мире. Обучение в Гарвардской школе бизнеса (Harvard Business School, HBS) практически полностью построено на анализе кейсов, а в библиотеке школы собрана самая большая коллекция кейсов в мире. Классический гарвардский кейс — это большой по объему кейс (20–25 страниц текста плюс 8–10 страниц иллюстраций и приложений), где есть главный герой и его история. Особенность применения кейс-метода в HBS — поиск единственно верного решения.

В Школе управления им. Дж. Кеннеди (John F. Kennedy School of Government, HKS) кейсы применяются для обучения государственных служащих, и их темы связаны с вопросами государственной политики и лидерства. Главный герой кейса, как правило, находится на государственной службе или является официальным лицом некоммерческой организации. Кейсы HKS могут затрагивать такие темы, как «Возрождение Руанды после геноцида», «Ураган Катрина» и т. п. Обсуждение кейсов в HKS носит скорее научный и концептуальный характер, в то время как в бизнес-школах кейс-метод — это решение конкретной проблемы с разработкой плана действий.

В медицинском образовании примером использования кейс-метода может служить обучение в Медицинской школе Гарварда (Harvard Medical School). Традиционно будущих врачей допускали до работы с пациентами с третьего курса, а первые два года им давалось исключительно теоретическое образование с огромным объемом материала для запоминания. Студенты изучали биологию, физиологию, анатомию, биохимию и другие дисциплины. В 1985 году декан школы Даниэль Тостезон (Daniel Tosteson) предложил использовать кейсы для того, чтобы снизить информационную нагрузку на студентов и ввести в программу элементы активного обучения.

Работа с медицинскими кейсами отличалась от решения бизнес-кейсов своим форматом. Студенты работали в небольших группах, по 6–8 человек, и получали материал непосредственно на занятии, а не знакомились с ним заранее. Кейс состоял из 5–6 частей, которые последовательно разбирались на нескольких занятиях. Как правило, в первой части описывалось начальное состояние пациента и симптомы болезни, вторая содержала в себе результаты первичного осмотра, последующие части были посвящены результатам анализов, диагнозу специалистов, назначенному лечению, реакции пациента на это лечение и дальнейшему прогрессу лечения.

В ходе обсуждения от студентов не требовалось предлагать готовые решения. Цель заключалась в том, чтобы поставить дальнейшие вопросы, выдвинуть гипотезы, выявить пробелы в знаниях и в итоге сформировать план для самостоятельного изучения материалов по теме, с которым студенты на несколько дней отправлялись работать в библиотеку. После этого преподаватель предлагал для обсуждения следующую часть кейса. Таким образом, с введением кейсов в обучение студенты уже на начальных курсах погружались в мир врачебной практики вместо чисто теоретической подготовки.

В европейской традиции бизнес-образования изначально утвердился немного иной формат обучения. Первые программы МВА во Франции, Швейцарии, Великобритании и других странах длились в среднем 12 месяцев (вместо двухгодичных программ, как это было принято в США) и были рассчитаны на студентов, уже обладавших практическим опытом в управлении бизнесом.

Эта прагматическая ориентация и приближенность к миру реального бизнеса нашла свое наиболее законченное выражение в Манчестерской школе бизнеса (Manchester Business School, MBS) и, соответственно, так называемой манчестерской школе кейсов. В отличие от гарвардских кейсов манчестерские кейсы в полтора-два раза короче и в них принципиально отсутствует правильное решение, которое вырабатывается в ходе открытых обсуждений. Кроме того, Манчестерская школа бизнеса пытается еще больше приблизить свои кейсы к реальности: она практикует краткосрочные стажировки студентов (проектный метод обучения), где перед ними ставится задача справиться с конкретной трудностью, которую компания испытывает в настоящий момент. За счет прохождения практики обучение в MBS длится чуть больше — 18 месяцев. В среднем на лекции приходится 30 % всего учебного времени, решение кейсов занимает 25 %, а участие в рабочих проектах — 45 %.

Интересные факты о кейсах

• Каждый год преподаватели HBS создают на основе реальных бизнес-ситуаций около 350 кейсов. На написание кейса уходит от одного до четырех месяцев.
• В разгар Второй мировой войны преподаватели HBS написали 600 специальных кейсов для обучения военных сотрудников.
• В среднем за два года каждый слушатель программы МВА в HBS изучает 500–600 кейсов и тратит на это до 80–90 % своего учебного времени.
• В HBS распространена практика, когда реальный прототип главного героя кейса присутствует при его разборе (лично или в видеорежиме), отвечает на вопросы студентов, комментирует их решение и объясняет, как и почему он поступил в реальной ситуации.
• В мае 2008 года в HBS было принято решение диверсифицировать формат кейсов, сделать их более изящными, литературными, в яркой обложке и продавать как книги возле касс в магазинах. Подобные кейсы могут предназначаться, например, для домохозяек. Для этого HBS уже подписала контракт с популярным американским автором женских романов Даниэлой Стил.
• Считается, что чаще всего героями кейсов являются топ-менеджеры. Однако также существуют кейсы, посвященные спортсменам, деятелям культуры, общественным лидерам и государственным служащим. Так, известны кейсы, посвященные бывшему главному тренеру «Манчестер Юнайтед» сэру Алексу Фергюсону, теннисистке Марии Шараповой и даже Леди Гаге.
• В HBS функционирует Kids Case Discussions — специальный детский класс для детей выпускников школы. Занятия проводят преподаватели университета, и дети обсуждают с ними настоящие, неадаптированные гарвардские кейсы
• Около 80 % кейсов, использующихся для обучения во всем мире, написаны преподавателями Гарвардской школы бизнеса (HBS). Эти бизнес-задачи подробно разбираются на Школе Changellenge >>, а знания применяются на практике. Вы на протяжении одной недели будете вместе с другими участниками интенсива реализовывать консалтинговый проект с настоящим клиентом.

Рекомендуем:

• Как организовать эффективную работу в команде?
• Готовься к кейсам, которые помогут попасть на работу мечты
• Как решать IT- кейс?
• Как решать кейсы

Теги

Получите карьерную поддержку

Если вы не знаете, с чего начать карьеру, зашли в тупик или считаете, что совершили какие-то ошибки, спросите совета у специалистов. Заполните заявку и консультанты Changellenge >> окажут вам помощь. Это отличный шанс вместе экспертом проработать проблемные вопросы и составить карьерный план.

Подписаться на карьерную рассылку

Подписывайтесь на рассылку и получайте карьерные советы — от выбора индустрии и компании до лайфхаков по самоорганизации и развитию коммуникативных навыков.

Стажер ML Sber AI Lab

Стажер-консультант по внедрению бизнес-приложений

Стажер-аналитик

Стажер по защите инфраструктуры

Стажер-тестировщик (Управление склейкой товаров, Торговая площадка)

Стажёр UX исследователь, Ozon Tech

Стажер DevOps

Лидерская программа Mars

Источник: changellenge.com