По User Story не написать документацию
User Story и Use Case сравнивают по самым разным критериям. Мне нравится сравнение по одному неочевидному пункту. Возможно, эта мысль станет для кого-то новой.
📌 По юз кейсам можно вести документацию, а по юзер стори — нет.
Почему?
👉 User Story в формате «Я, как пользователь, хочу..., чтобы...» отражает намерение, но не даёт подробностей. Она не объясняет, как именно реализован программный продукт. Даже с критериями приемки сложно понять, как работает система в целом.
👉 Use Case, напротив, позволяет вести документацию. Сначала он пишется как часть ТЗ, а после реализации становится документацией.
User Story помогает понять что нужно, а Use Case объясняет как это работает.
#usecase #documentation
User Story и Use Case сравнивают по самым разным критериям. Мне нравится сравнение по одному неочевидному пункту. Возможно, эта мысль станет для кого-то новой.
📌 По юз кейсам можно вести документацию, а по юзер стори — нет.
Почему?
👉 User Story в формате «Я, как пользователь, хочу..., чтобы...» отражает намерение, но не даёт подробностей. Она не объясняет, как именно реализован программный продукт. Даже с критериями приемки сложно понять, как работает система в целом.
👉 Use Case, напротив, позволяет вести документацию. Сначала он пишется как часть ТЗ, а после реализации становится документацией.
User Story помогает понять что нужно, а Use Case объясняет как это работает.
#usecase #documentation
👍12✍3🔥3💯1
Use Case — это не про «писать», это про «мыслить»
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
С Use Case у меня любовь с первого взгляда.
Впервые я узнала об этой технике в ВУЗе. Именно эти знания помогли мне устроиться на первую работу. В качестве тестового задания нужно было проработать все юз кейсы по процессу восстановления пароля VK. Проверяющий оценил мое внимание к деталям, ведь я описала десятки альтернативных сценариев. 😅
С тех пор Use Cases стали частью многих моих проектов. Где-то у описания задачи юз кейс — это был обязательный пункт шаблона, а где-то мы полноценно вели документацию по продукту в формате юз кейс.
Из абсурдного и забавного:
Как то меня заставили писать юз кейсы для распила бюджета, где важно было не качество, а количество написанных страниц. 🤦♀️
Для меня техника Use Case — не способ писать, а способ мыслить. Прорабатывая сценарий по шаблону, у аналитика все требования раскладываются по полочкам.
📌 Оформление — вторично. Требования можно оформить хоть в виде списка в вордовском документе или в конфлюенсе, на бумаге, на стикере, да хоть мелом на асфальте. 😅
📌 Первично — продумать, а что будем делать. И техника Use Case учит именно думать, а не только писать.
Попробуйте использовать Use Case на своих проектах — техника действительно работает!
#usecase #documentation #sa_dev
Рубрика: взгляд системного аналитика на процессы, кейсы, боли, холиварные темы
Привет! 👋
С вами Вера, основатель AnalystCore и автор этого канала.
С Use Case у меня любовь с первого взгляда.
Впервые я узнала об этой технике в ВУЗе. Именно эти знания помогли мне устроиться на первую работу. В качестве тестового задания нужно было проработать все юз кейсы по процессу восстановления пароля VK. Проверяющий оценил мое внимание к деталям, ведь я описала десятки альтернативных сценариев. 😅
С тех пор Use Cases стали частью многих моих проектов. Где-то у описания задачи юз кейс — это был обязательный пункт шаблона, а где-то мы полноценно вели документацию по продукту в формате юз кейс.
Из абсурдного и забавного:
Как то меня заставили писать юз кейсы для распила бюджета, где важно было не качество, а количество написанных страниц. 🤦♀️
Для меня техника Use Case — не способ писать, а способ мыслить. Прорабатывая сценарий по шаблону, у аналитика все требования раскладываются по полочкам.
📌 Оформление — вторично. Требования можно оформить хоть в виде списка в вордовском документе или в конфлюенсе, на бумаге, на стикере, да хоть мелом на асфальте. 😅
📌 Первично — продумать, а что будем делать. И техника Use Case учит именно думать, а не только писать.
Попробуйте использовать Use Case на своих проектах — техника действительно работает!
#usecase #documentation #sa_dev
👍6❤🔥5💯4
Альтернативные сценарии в процессе авторизации
Ранее вы прорабатывали альтернативные сценарии для процесса авторизации 👆
Спасибо всем, кто поучаствовал.
Давайте дополним этот список:
✏️ Истекший срок действия пароля — пользователь пытается войти, но его пароль больше не актуален и требует обновления.
✏️ Учетная запись заблокирована — например, из-за подозрительной активности или нарушений правил.
✏️ Попытка входа с неизвестного устройства — система запрашивает дополнительное подтверждение (например, код из 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