Альтернативные сценарии в процессе авторизации
Ранее вы прорабатывали альтернативные сценарии для процесса авторизации 👆
Спасибо всем, кто поучаствовал.
Давайте дополним этот список:
✏️ Истекший срок действия пароля — пользователь пытается войти, но его пароль больше не актуален и требует обновления.
✏️ Учетная запись заблокирована — например, из-за подозрительной активности или нарушений правил.
✏️ Попытка входа с неизвестного устройства — система запрашивает дополнительное подтверждение (например, код из SMS).
✏️ Превышение времени сессии на странице авторизации — пользователь слишком долго заполнял данные, и сессия авторизации истекла.
✏️ Попытка входа в аккаунт без подтвержденной почты — система просит завершить регистрацию или подтвердить email.
✏️ Вход с VPN или из другой страны — система может запросить дополнительное подтверждение личности.
✏️ Неверный или отсутствующий токен безопасности — например, при попытке входа через сохраненную ссылку на форму авторизации.
Если у вас есть еще идеи, пишите в комментарии 👇
#usecase
Ранее вы прорабатывали альтернативные сценарии для процесса авторизации 👆
Спасибо всем, кто поучаствовал.
Давайте дополним этот список:
✏️ Истекший срок действия пароля — пользователь пытается войти, но его пароль больше не актуален и требует обновления.
✏️ Учетная запись заблокирована — например, из-за подозрительной активности или нарушений правил.
✏️ Попытка входа с неизвестного устройства — система запрашивает дополнительное подтверждение (например, код из SMS).
✏️ Превышение времени сессии на странице авторизации — пользователь слишком долго заполнял данные, и сессия авторизации истекла.
✏️ Попытка входа в аккаунт без подтвержденной почты — система просит завершить регистрацию или подтвердить email.
✏️ Вход с VPN или из другой страны — система может запросить дополнительное подтверждение личности.
✏️ Неверный или отсутствующий токен безопасности — например, при попытке входа через сохраненную ссылку на форму авторизации.
Если у вас есть еще идеи, пишите в комментарии 👇
#usecase
👍7🔥4❤2✍1
Как писала ранее, Use Case оформляются по шаблону. И следовать ему нужно не для красивого оформления, а для качественной проработки логики работы системы.
Что вообще такое Use Case?
📌 Use Case — это описание того, как пользователь, другая система или любой другой объект взаимодействует с системой для достижения определённой цели.
Вернемся к прошлому примеру про запись на прием к врачу и заполним остальные пункты шаблона.
Название Use Case (Цель): Записаться на прием к врачу.
Действующие лица: Пользователь (пациент).
Минимальные гарантии:
* Пользователь увидит форму записи на прием к врачу.
Гарантии успеха:
* Пользователь успешно записан на прием к врачу.
* Система отправляет подтверждение на электронную почту или телефон.
Триггер: Пользователь решает записаться на прием к врачу.
Предусловие: Пользователь авторизован в системе.
Основной сценарий:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Пользователь указывает свой email
6️⃣ Система резервирует слот, врача и кабинет.
7️⃣ Система отправляет письмо с уведомлением о записи на указанный email.
Расширения:
1.а. Врач отсутствует в списке (например, пользователь неправильно ввел ФИО врача).
2.а. У выбранного врача нет свободных слотов.
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4.а. Введенное количество символов превышает максимально допустимое.
5.а. Введен email не по формату *@*.*
6.а. Врач или кабинет уже заняты в это время.
6.b. Техническая ошибка при резервировании.
7.а. Почта пользователя указана неверно.
7.b. Почтовый сервер недоступен.
#usecase #documentation
Что вообще такое Use Case?
📌 Use Case — это описание того, как пользователь, другая система или любой другой объект взаимодействует с системой для достижения определённой цели.
Вернемся к прошлому примеру про запись на прием к врачу и заполним остальные пункты шаблона.
Название Use Case (Цель): Записаться на прием к врачу.
Действующие лица: Пользователь (пациент).
Минимальные гарантии:
* Пользователь увидит форму записи на прием к врачу.
Гарантии успеха:
* Пользователь успешно записан на прием к врачу.
* Система отправляет подтверждение на электронную почту или телефон.
Триггер: Пользователь решает записаться на прием к врачу.
Предусловие: Пользователь авторизован в системе.
Основной сценарий:
1️⃣ Пользователь выбирает врача.
2️⃣ Система отображает доступные слоты.
3️⃣ Пользователь выбирает дату и время.
4️⃣ Пользователь вводит причину обращения.
5️⃣ Пользователь указывает свой email
6️⃣ Система резервирует слот, врача и кабинет.
7️⃣ Система отправляет письмо с уведомлением о записи на указанный email.
Расширения:
1.а. Врач отсутствует в списке (например, пользователь неправильно ввел ФИО врача).
2.а. У выбранного врача нет свободных слотов.
3.а. Выбранный слот был забронирован другим пользователем параллельно.
3.b. Пользователь вводит дату вручную, формат некорректен.
4.а. Введенное количество символов превышает максимально допустимое.
5.а. Введен email не по формату *@*.*
6.а. Врач или кабинет уже заняты в это время.
6.b. Техническая ошибка при резервировании.
7.а. Почта пользователя указана неверно.
7.b. Почтовый сервер недоступен.
#usecase #documentation
👍7✍3🔥2🤔1
Название Use Case — не просто название
Это цель действующего лица, которую оно хочет достичь с помощью системы.
✅ UC «Записаться к врачу» — цель Пациента.
✅ UC «Заполнить карточку», «Отредактировать карточку», «Просмотреть карточку» — цели врача.
✅ UC «Просмотреть расписание врача», «Изменить запись» — цели администратора клиники.
..........
Думаете, мы все разобрали по теме Use Case?
Спойлер: конечно же, нет
Как обсуждали в предыдущих постах (ищите их по хэштегу #usecase), UC — это не просто формальный документ. Это инструмент мышления и анализа.
UC — интереснее, чем кажется. А вы знали, что:
❗ Участник в UC — это не просто пользователь.
❗ Минимальные и максимальные гарантии действительно важно продумывать.
❗ Без идентификаторов UC теряют потенциал для трассировки требований.
❗ Как правильно ссылаться на UC и зачем это нужно?
❗ Как UC интегрируются с другими документами/артефактами системного анализа?
❗ Как грамотно оформлять расширения, избегать дублирования шагов и не превращать UC в 100-страничный документ?
и пр.
Ответить на все эти вопросы в рамках коротких постов сложно. Нужны практика и полное погружение.
👉 Рекомендуем: изучите статьи в интернете, прочитайте книги и попробуйте применять эту технику на своих проектах.
#usecase
https://analystcore.com/#program
Это цель действующего лица, которую оно хочет достичь с помощью системы.
✅ UC «Записаться к врачу» — цель Пациента.
✅ UC «Заполнить карточку», «Отредактировать карточку», «Просмотреть карточку» — цели врача.
✅ UC «Просмотреть расписание врача», «Изменить запись» — цели администратора клиники.
..........
Думаете, мы все разобрали по теме Use Case?
Как обсуждали в предыдущих постах (ищите их по хэштегу #usecase), UC — это не просто формальный документ. Это инструмент мышления и анализа.
UC — интереснее, чем кажется. А вы знали, что:
❗ Участник в UC — это не просто пользователь.
❗ Минимальные и максимальные гарантии действительно важно продумывать.
❗ Без идентификаторов UC теряют потенциал для трассировки требований.
❗ Как правильно ссылаться на UC и зачем это нужно?
❗ Как UC интегрируются с другими документами/артефактами системного анализа?
❗ Как грамотно оформлять расширения, избегать дублирования шагов и не превращать UC в 100-страничный документ?
и пр.
Ответить на все эти вопросы в рамках коротких постов сложно. Нужны практика и полное погружение.
👉 Рекомендуем: изучите статьи в интернете, прочитайте книги и попробуйте применять эту технику на своих проектах.
А если хотите быстрее освоить Use Case, приглашаем вас на курс AnalystCore!Мы рассказываем, как UC вписываются в требования, учим прорабатывать сценарии и раскрываем весь потенциал этой техники для работы системного аналитика. 👊Если есть вопросы по программе, пишите нам в ЛС 👉 @analystcoreteam
#usecase
https://analystcore.com/#program
👍5🔥4🆒2
Приглашаем вас поучаствовать в создании контента этого канала!💡
Насколько вам понятен текущий уровень материалов на канале?
Пройдите опрос ниже 👇
Мы стремимся делать наши публикации максимально полезными и интересными для вас. Выберите вариант, который лучше всего отражает ваши ощущения.
Напоминаем! У нас есть второй канал — AnalystCore -> Старт карьеры.
Там мы:
✅ Объясняем теорию простыми словами,
✅ Даем практические упражнения,
✅ Мотивируем учиться и развиваться в профессии.
Присоединяйтесь! 🚀
Насколько вам понятен текущий уровень материалов на канале?
Пройдите опрос ниже 👇
Мы стремимся делать наши публикации максимально полезными и интересными для вас. Выберите вариант, который лучше всего отражает ваши ощущения.
Напоминаем! У нас есть второй канал — AnalystCore -> Старт карьеры.
Там мы:
✅ Объясняем теорию простыми словами,
✅ Даем практические упражнения,
✅ Мотивируем учиться и развиваться в профессии.
Присоединяйтесь! 🚀
🔥5👍2
Насколько вам понятен текущий уровень материалов на канале? Ваш голос поможет нам адаптировать контент под ваши ожидания!
Anonymous Poll
76%
💡 Всё отлично, материалы понятны и полезны.
14%
🤔 Иногда сложно, хочется больше примеров и пояснений.
0%
😅 Часто сложно, лучше больше фокусироваться на базовых вещах и теории.
10%
🚀 Слишком просто, можно углубить уровень проработки.
👍6🔥2
Кэширование данных на фронтенде
Ранее мы делились шаблоном для постановки задачи на фронтенд. Но это еще не всё, что хочет получить разработчик! ✨
На фронтенде часто используют кэширование, чтобы:
* на странице быстрее загружались данные,
* не нагружать лишний раз сервер.
Какую роль играет системный аналитик в проработке кэширования?
📌 Мы помогаем ответить на важные вопросы:
* Какие данные нужно кэшировать?
* Сколько времени данные остаются актуальными?
* Что делать, если кэш устарел?
Примеры данных, которые можно закэшировать:
* Значения справочников (страны, валюты, категории услуг).
* Информация о пользователе (если она редко меняется).
* Результаты фильтров, например, товары по заданным критериям.
* Настройки интерфейса (тема, язык).
Пример ТЗ:
Вызвать метод GET <uri> с параметрами <указываем параметры и откуда их брать>.
- Если в ответе пришел http-код = 200, то закэшировать ответ на 5 минут.
- Иначе отобразить ошибку в алерте с текстом из <указываем параметры>.
#frontend
Ранее мы делились шаблоном для постановки задачи на фронтенд. Но это еще не всё, что хочет получить разработчик! ✨
На фронтенде часто используют кэширование, чтобы:
* на странице быстрее загружались данные,
* не нагружать лишний раз сервер.
Какую роль играет системный аналитик в проработке кэширования?
📌 Мы помогаем ответить на важные вопросы:
* Какие данные нужно кэшировать?
* Сколько времени данные остаются актуальными?
* Что делать, если кэш устарел?
Примеры данных, которые можно закэшировать:
* Значения справочников (страны, валюты, категории услуг).
* Информация о пользователе (если она редко меняется).
* Результаты фильтров, например, товары по заданным критериям.
* Настройки интерфейса (тема, язык).
Пример ТЗ:
Вызвать метод GET <uri> с параметрами <указываем параметры и откуда их брать>.
- Если в ответе пришел http-код = 200, то закэшировать ответ на 5 минут.
- Иначе отобразить ошибку в алерте с текстом из <указываем параметры>.
#frontend
👍8✍4
👉 Поделитесь, сталкивались ли вы с задачами кэширования? Что было самым сложным? 💬
Anonymous Poll
14%
1️⃣ Да, определял(а), что кэшировать
11%
2️⃣ Да, сложно было выбрать время жизни кэша
11%
3️⃣ Да, возникали проблемы с устаревшими данными
68%
4️⃣ Нет, с задачами кэширования не сталкивался(ась)
👍5
Single Page Application (SPA)
В продолжение темы кэширования давайте разберём, что такое SPA и почему кэширование здесь особенно важно.
SPA (Single Page Application) — это веб-приложение, где переходы между страницами происходят без перезагрузки. Все данные загружаются динамически через API. Это обеспечивает быструю работу приложения и плавный пользовательский опыт.
Почему кэширование в SPA важно?
📌 Для мгновенной загрузки данных без обращения к серверу.
📌 Для минимизации запросов к серверу и экономии ресурсов.
📌 Для поддержания работы в офлайн-режиме (где это необходимо).
Например, значения справочников, настройки пользователя или результаты поиска можно хранить в локальном кэше и обновлять по мере необходимости.
#frontend
В продолжение темы кэширования давайте разберём, что такое SPA и почему кэширование здесь особенно важно.
SPA (Single Page Application) — это веб-приложение, где переходы между страницами происходят без перезагрузки. Все данные загружаются динамически через API. Это обеспечивает быструю работу приложения и плавный пользовательский опыт.
Почему кэширование в SPA важно?
📌 Для мгновенной загрузки данных без обращения к серверу.
📌 Для минимизации запросов к серверу и экономии ресурсов.
📌 Для поддержания работы в офлайн-режиме (где это необходимо).
Например, значения справочников, настройки пользователя или результаты поиска можно хранить в локальном кэше и обновлять по мере необходимости.
#frontend
👍9❤3🔥3
Local Storage и Session Storage
В продолжение темы кэширования давайте поговорим о Local Storage и Session Storage — двух типах хранилищ данных на стороне клиента.
📌 Local Storage — это хранилище данных, которое сохраняет информацию на длительный срок, даже после закрытия браузера.
📌 Session Storage — данные хранятся только на время сессии браузера (до закрытия вкладки).
Пример_1:
Представьте, что вы на сайте онлайн-курса, и можете начать его проходить без регистрации. В какой-то момент вас просят ввести email, и без этого продолжить обучение невозможно.
❗️После регистрации вы ожидаете, что ваш прогресс не исчезнет, а будет перенесен на ваш аккаунт. И вот тут на помощь приходит Local Storage: он позволяет сохранить ваш прогресс в неавторизованной зоне. Когда вы авторизуетесь, данные о вашем прогрессе подтягиваются, сохраняются на сервере, и вам не придется проходить уроки заново.
Пример_2:
Представьте, что вы заполняете форму для записи на прием к врачу (вводите дату, выбираете врача, пишете причину обращения). Нажимаете на ссылку, чтобы посмотреть карточку врача, а затем возвращаетесь обратно на форму.
❗️Благодаря Session Storage все введенные вами данные сохраняются, и после возврата они подтягиваются, как будто вы не покидали страницу. Однако если вы закроете вкладку или браузер, данные исчезнут, и вам нужно будет снова заполнять форму.
#frontend
В продолжение темы кэширования давайте поговорим о Local Storage и Session Storage — двух типах хранилищ данных на стороне клиента.
📌 Local Storage — это хранилище данных, которое сохраняет информацию на длительный срок, даже после закрытия браузера.
📌 Session Storage — данные хранятся только на время сессии браузера (до закрытия вкладки).
Пример_1:
Представьте, что вы на сайте онлайн-курса, и можете начать его проходить без регистрации. В какой-то момент вас просят ввести email, и без этого продолжить обучение невозможно.
❗️После регистрации вы ожидаете, что ваш прогресс не исчезнет, а будет перенесен на ваш аккаунт. И вот тут на помощь приходит Local Storage: он позволяет сохранить ваш прогресс в неавторизованной зоне. Когда вы авторизуетесь, данные о вашем прогрессе подтягиваются, сохраняются на сервере, и вам не придется проходить уроки заново.
Пример_2:
Представьте, что вы заполняете форму для записи на прием к врачу (вводите дату, выбираете врача, пишете причину обращения). Нажимаете на ссылку, чтобы посмотреть карточку врача, а затем возвращаетесь обратно на форму.
❗️Благодаря Session Storage все введенные вами данные сохраняются, и после возврата они подтягиваются, как будто вы не покидали страницу. Однако если вы закроете вкладку или браузер, данные исчезнут, и вам нужно будет снова заполнять форму.
#frontend
🔥7👍3✍2
Кейс:
Представьте, что вы заказываете билеты на мероприятие через сайт. На первой странице вы выбираете количество билетов, дату и время мероприятия. На второй странице — выбираете места и т.д. Однако вы случайно закрыли вкладку до завершения оформления.
❓ Вопрос: где стоит хранить информацию о выбранных билетах: в Local Storage или Session Storage?
Представьте, что вы заказываете билеты на мероприятие через сайт. На первой странице вы выбираете количество билетов, дату и время мероприятия. На второй странице — выбираете места и т.д. Однако вы случайно закрыли вкладку до завершения оформления.
❓ Вопрос: где стоит хранить информацию о выбранных билетах: в Local Storage или Session Storage?
🔥8
Где стоит хранить информацию о выбранных билетах: в Local Storage или Session Storage? Кейс см. ранее 👆
Anonymous Quiz
56%
Local Storage
44%
Session Storage
👍8❤3
Кэширование данных: что, как и насколько?
Представим, что на странице вызываются методы:
* GET /countries — список стран.
* GET /user/profile — данные о текущем пользователе.
❗Почему стоит кэшировать ответы и насколько?
GET /countries
Это справочные данные, которые редко меняются. Их можно закэшировать в Local Storage на сутки или дольше, чтобы не запрашивать их каждый раз при загрузке страницы.
GET /user/profile
Это динамические данные, они меняются редко, но должны быть актуальными. Их можно кэшировать в Session Storage на одну сессию, чтобы уменьшить количество запросов, пока пользователь активен.
💡Конечно же, не стоит забывать об обновлении кэша. Да, мы закэшировали данные пользователя, но ведь пользователь может отредактировать свой профиль в приложении. В таком случае нужно настроить логику, чтобы при редактировании данные в кэше обновлялись.
💡А еще не забываем учитывать, что есть разные пути изменения данных:
* через мобильное приложение,
* веб-версию,
* напрямую в базе данных,
* через API,
и др.
Все эти факторы нужно учитывать и исходя из этого выбирать время жизни кэша.
#frontend
Представим, что на странице вызываются методы:
* GET /countries — список стран.
* GET /user/profile — данные о текущем пользователе.
❗Почему стоит кэшировать ответы и насколько?
GET /countries
Это справочные данные, которые редко меняются. Их можно закэшировать в Local Storage на сутки или дольше, чтобы не запрашивать их каждый раз при загрузке страницы.
GET /user/profile
Это динамические данные, они меняются редко, но должны быть актуальными. Их можно кэшировать в Session Storage на одну сессию, чтобы уменьшить количество запросов, пока пользователь активен.
💡Конечно же, не стоит забывать об обновлении кэша. Да, мы закэшировали данные пользователя, но ведь пользователь может отредактировать свой профиль в приложении. В таком случае нужно настроить логику, чтобы при редактировании данные в кэше обновлялись.
💡А еще не забываем учитывать, что есть разные пути изменения данных:
* через мобильное приложение,
* веб-версию,
* напрямую в базе данных,
* через API,
и др.
Все эти факторы нужно учитывать и исходя из этого выбирать время жизни кэша.
#frontend
👍7✍5🔥4❤1
Любите ставить задачи для фронтендеров?
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
Мне особенно нравится делиться с вами контентом про фронтенд.
В Т-Инвестиции я работала в команде чисто фронта и хорошо прокачалась в вопросах, какие боли есть у фронтендеров, чего им не хватает в ТЗ от системного аналитика.
Знали такое разделение на проекте? На проекте могут быть команды:
1️⃣ веба
2️⃣ ios
3️⃣ android
4️⃣ команды бэка на каждый сервис.
Подобное разделение я видела и в дальнейшем на многих крупных проектах.
В остальном, я была в классических командах, которые занимались и фронтом и бэком.
За время работы я поняла, что больше всего мне нравится работать там, где занимаются не только бэком, но и пользовательским интерфейсом. UI — наше всё. Ты пишешь ТЗ, а потом видишь, как оно оживает в готовом продукте.
Хочу и вам привить эту любовь к фронту ❤️
#frontend #sa_dev
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
Мне особенно нравится делиться с вами контентом про фронтенд.
В Т-Инвестиции я работала в команде чисто фронта и хорошо прокачалась в вопросах, какие боли есть у фронтендеров, чего им не хватает в ТЗ от системного аналитика.
Знали такое разделение на проекте? На проекте могут быть команды:
1️⃣ веба
2️⃣ ios
3️⃣ android
4️⃣ команды бэка на каждый сервис.
Подобное разделение я видела и в дальнейшем на многих крупных проектах.
В остальном, я была в классических командах, которые занимались и фронтом и бэком.
За время работы я поняла, что больше всего мне нравится работать там, где занимаются не только бэком, но и пользовательским интерфейсом. UI — наше всё. Ты пишешь ТЗ, а потом видишь, как оно оживает в готовом продукте.
Хочу и вам привить эту любовь к фронту ❤️
#frontend #sa_dev
👍9🔥4❤2
This media is not supported in your browser
VIEW IN TELEGRAM
СА: «Дедлайн к утру? Уже готово, смотри!»
Заказчик: «А это кто согласовал?»
Заказчик: «А это кто согласовал?»
🔥8😁5
База — наше всё!
Часто начинающий системный аналитик работает 1-2 года, а потом переходит в другую компанию. А при переходе впадает в ступор.
Или вы чувствуете себя неуверенно на текущей работе. Боитесь отклониться от примеров наставника, страшно сделать шаг влево, шаг вправо. Боитесь накосячить и опозориться перед коллегами. Знакомо? Это ощущение часто приходит от недостатка базы.
📌 База — это фундамент системного мышления аналитика. Как его развивать?
1️⃣ Насмотренность
Изучайте примеры работы других аналитиков, кейсы и подходы.
2️⃣ Алгоритмы
Учитесь не только их описывать, но и продумывать с нуля. Это помогает понимать логику работы систем.
3️⃣ Вопросы
Практикуйтесь задавать точные, полезные вопросы. Это навык, который превращает просто аналитика в профессионала.
У каждого свои пробелы в знаниях и опыте.
Вот что можно сделать:
💡Почитайте книги по навыку, который вы хотите подтянуть в ближайшее время. Например:
📚 «Writing Effective Use Cases», Алистер Коберн
📚 «Пользовательские истории. Искусство гибкой разработки ПО», Паттон Джефф
📚 «Не заставляйте меня думать. Веб-юзабилити и здравый смысл», Стив Круг
📚 «Микросервисы», Крис Ричардсон — актуально, если у вас на проекте микросервисная архитектура. Даже если вы новичок, вы поймете 20% книги, а это уже хорошо!
💡Заведите себе челлендж — изучать по 1 новому кейсу в день. Для этого подойдут статьи на Хабре.
💡Потратьте время на разбор процессов, которые вас окружают. Как они устроены (AS IS)? Как их можно улучшить (TO BE)?
Вы сможете преодолеть неуверенность, расширить кругозор и двигаться к большему. Главное — начните. У вас всё получится!
С вами Вера и Юрий,
основатели AnalystCore ❤️
Часто начинающий системный аналитик работает 1-2 года, а потом переходит в другую компанию. А при переходе впадает в ступор.
Здесь все по-другому! Процессы другие, терминология другая, все непривычно. 😵💫
Или вы чувствуете себя неуверенно на текущей работе. Боитесь отклониться от примеров наставника, страшно сделать шаг влево, шаг вправо. Боитесь накосячить и опозориться перед коллегами. Знакомо? Это ощущение часто приходит от недостатка базы.
📌 База — это фундамент системного мышления аналитика. Как его развивать?
1️⃣ Насмотренность
Изучайте примеры работы других аналитиков, кейсы и подходы.
2️⃣ Алгоритмы
Учитесь не только их описывать, но и продумывать с нуля. Это помогает понимать логику работы систем.
3️⃣ Вопросы
Практикуйтесь задавать точные, полезные вопросы. Это навык, который превращает просто аналитика в профессионала.
У каждого свои пробелы в знаниях и опыте.
Вот что можно сделать:
💡Почитайте книги по навыку, который вы хотите подтянуть в ближайшее время. Например:
📚 «Writing Effective Use Cases», Алистер Коберн
📚 «Пользовательские истории. Искусство гибкой разработки ПО», Паттон Джефф
📚 «Не заставляйте меня думать. Веб-юзабилити и здравый смысл», Стив Круг
📚 «Микросервисы», Крис Ричардсон — актуально, если у вас на проекте микросервисная архитектура. Даже если вы новичок, вы поймете 20% книги, а это уже хорошо!
💡Заведите себе челлендж — изучать по 1 новому кейсу в день. Для этого подойдут статьи на Хабре.
💡Потратьте время на разбор процессов, которые вас окружают. Как они устроены (AS IS)? Как их можно улучшить (TO BE)?
Вы сможете преодолеть неуверенность, расширить кругозор и двигаться к большему. Главное — начните. У вас всё получится!
С вами Вера и Юрий,
основатели AnalystCore ❤️
❤13👍7🔥4
Реальность перехода в новую компанию
Привет! 👋
С вами Вера.
После нового года многие задумываются о смене работы. А если это ваше 2-е или 3-е место, собеседования могут быть стрессовыми 😩. Как к ним подготовиться?
📌 Повторяйте базу и делайте себе шпаргалки.
Лично я перед собеседованиями всегда обращаюсь к своим заметкам, которые делала 3 года назад, 4, 5, 7 лет назад. Даже многое из того, что писала 5 лет назад, актуально до сих пор — не нужно искать всё заново, просто открываешь и освежаешь память. Это экономит время и нервы.
📌 Будьте готовы к тому, что на новом месте задачи могут быть совершенно другими.
На одном проекте вы просто описывали требования, а на другом нужно будет писать детальные ТЗ для фронтендеров и продумывать кэширование. Или, например, раньше вы проектировали логическую модель данных, а теперь будете делать физическую модель с учетом особенностей СУБД.
#sa_dev
Привет! 👋
С вами Вера.
После нового года многие задумываются о смене работы. А если это ваше 2-е или 3-е место, собеседования могут быть стрессовыми 😩. Как к ним подготовиться?
📌 Повторяйте базу и делайте себе шпаргалки.
Лично я перед собеседованиями всегда обращаюсь к своим заметкам, которые делала 3 года назад, 4, 5, 7 лет назад. Даже многое из того, что писала 5 лет назад, актуально до сих пор — не нужно искать всё заново, просто открываешь и освежаешь память. Это экономит время и нервы.
📌 Будьте готовы к тому, что на новом месте задачи могут быть совершенно другими.
На одном проекте вы просто описывали требования, а на другом нужно будет писать детальные ТЗ для фронтендеров и продумывать кэширование. Или, например, раньше вы проектировали логическую модель данных, а теперь будете делать физическую модель с учетом особенностей СУБД.
#sa_dev
❤🔥6👍5🔥3