ПРО АНАЛИТИКА | КАНАЛ ПРО СИСТЕМНЫЙ АНАЛИЗ В АЙТИ

Готовые шаблоны - польза или вред? Вчера в чате курса увидел сообщение от ученика, не мог пойти мимо, так как мне важно, чтобы ученики получали точно результат, а сегодня хочу рассмотреть подробно с вами его ситуацию Собрал четко требования , точней продумал сам всю логику и как должно это выглядеть Посмотрел обучение постановка тз на бэк с внешней системой Мы сейчас интегрируемся с 1с , они создают сервис и мы будем его дергать , но у нас своей апишки нет к примеру . Бэк говорит что мы просто будем туда обращаться , тянуть данные и создавать уведомления и задачи Я могу по тому шаблону расписать Бизнес часть Логику И тот сервис который 1с нам создаст ? *орфография автора сохранена Погнали 🚀 С чего стоит начать в ситуациях, когда ничего не понятно? 1️⃣ Точно не надо бежать и использовать какой-то шаблон, а для начала нужно разобраться в требованиях. ✔️ Что нужно, ✔️ Как должно работать, ✔️ Какие системы участвуют и так далее. То есть сформировать в голове, а лучше в документе, то как сейчас и как должно быть. ➡️ Из сообщения видно, что с точки зрения бизнеса более-менее понятно, а вот с точки зрения систем - есть вопросы. Но так как я не работаю с системой, то чтобы дать совет, который реально поможет мне надо выяснить: ✔️ что за CRM, ✔️ как они планируют ее вызывать, ✔️ какие особенности у 1С и так далее. Потому что реализаций может быть достаточно много. Например, ✔️ CRM может напрямую вызывать 1с при определенном действии пользователя с фронта, тогда нужно взять шаблон из курса на постановку между фронтом и бэком. ✔️ CRM может по шедуллеру выполнять какие-то действия, а можно сделать APIшку и в этом варианте развития событий ученику понадобиться шаблон из курса на проектирование API, но с небольшими изменениями. Обсудив детали, я с учеником пришел к понимаю, что реализация будет через шедуллер. Дальше, уже дело техники. Просто делаем описание, обращаем внимание на важные моменты в спеке и вуаля, все готово. Но шаблон - это уже финальный этап и прежде чем до него добраться Вам надо сделать определенные шаги и чтобы ученику было легче - я еще сделал чек-лист по проектированию API, которым хочу поделиться с вами. Надеюсь, что этот чек-лист поможет и Вам избежать критических ошибок, ведь его можно использовать, как контрольный инструмент на каждом этапе разработки, чтобы не пропустить важные вещи при проектировании, разработке и внедрении API.

Yandex Go в Анталье Наконец-тоооо это случилось 🥳 Сейчас объясню почему я так этому рад Такси в Турции работает так: ✔️ Вызов происходит по кнопке, которая висит на дереве, нажимаешь ее и ждешь. Приедет ли к тебе водила и работает ли кнопка в целом - не узнаешь никак. ✔️ Ожидание, как вы понимаете, тоже бесконечно вечным может быть. А самое главное, что службы такси закреплены за районами и таксист с другого района, который может проезжать мимо, не возьмет тебя, потому что его могут просто за это отметелить, а пассажиров попросят пересесть в правильную машину. ➖➖➖ А теперь внимание вопрос, господа аналитики, что не так на скрине и что стоит поправить? 😁

ИЩУ АНАЛИТИКОВ, КОТОРЫЕ ХОТЯТ ВЫЙТИ НА НОВЫЙ УРОВЕНЬ В ПРОФЕССИИ ЧЕРЕЗ 5 НЕДЕЛЬ Да, да, всего за 5 недель можно прокачать себя в теме интеграций и проектирования API и выйти на новый уровень. Проверено участниками пяти потоков курса 🔥🔥🔥 И сегодня, я торжественно открываю продажи моего авторского курса-практикума «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API” ⬇️ ДЛИТЕЛЬНОСТЬ КУРСА - 5 недель Курс состоит из видео-уроков, а также 19 практических заданий после выполнения которых вы получите развернутую обратную связь лично от меня ДОПОЛНИТЕЛЬНО: 🔗 2 часовой онлайн вебинар в формате вопрос-ответ по итогам 5 недель обучения, 🔗 Чат поддержки и ответов на вопросы, который с вами останется навсегда и после окончания курса, 🔗 Сопроводительные материалы: конспекты к урокам, чек-листы, дополнительные файлы для наилучшего усвоения информации Доступ к материалам 3 месяца КОМУ ПОДХОДИТ КУРС: 🔘 системным аналитикам, 🔘 бизнес-аналитикам, 🔘 продакт менеджерам. КОТОРЫЕ ХОТЯТ: 🔗 понять с чего начать и научиться БАЗЕ в теме интеграций, тестировании и документировании требований, 🔗 освежить и углубить знания, а также разобраться, что там под "капотом", 🔗 прокачать свои технические знания, 🔗 научится разрабатывать ТЗ для разработчиков и подтянуть знания в этом вопросе, 🔗 заполнить пробелы в системном анализе для трудойстройства, 🔗 подтянуть для себя проектирование API или научиться понимать: как работает API, работе c JSON и научиться пользоваться такими инструментами, как Postman и Swagger, 🔗 познакомится с новыми людьми и коллегами и обменяться опытом КАКОЙ ТЕБЯ ЖДЁТ РЕЗУЛЬТАТ ПО ИТОГАМ КУРСА: Получишь практические навыки и сможешь: 📌 пройти тех собес в секции «интеграции», 📌 успешно применять в работе, 📌 сменить проект на более оплачиваемый и интересный Результаты тех, кто уже прошел курс можно изучить по тегу #отзыв 😉 ❗️ДЕЙСТВУЙ и ты и уже через 5 недель получишь первый результат❗️ ➖➖➖ ПОДРОБНЕЕ ПРО СТОИМОСТЬ И ПРОГРАММУ КУРСА, СПОСОБЫ ОПЛАТЫ И ТД 👉🏻 САЙТ КУРСА 👈🏻 👉🏻 САЙТ КУРСА 👈🏻 👉🏻 САЙТ КУРСА 👈🏻 ➖➖➖ образовательная лицензия No Л035-01298-77/01352304 от 16.08.2024

Как документировать ошибки в API? Сегодня про то, что часто пропускают и не особо продумывают в современных компаниях - API ошибки. Типичный кейс, как и с НФТ, что люди просто делают ctrl-c + ctrl-v. Однако, это классно работает, когда вы занимаетесь доработкой готовой системы, а что делать, если у вас что-то новое? Как быть? Прежде, чем ответить на этот вопрос, давайте скажу, почему важно думать про ошибки: ✔️ Легче анализировать возникающие проблемы, ✔️ Это юзер френдли и пользователи и разработчики вам за это скажут только спасибо. Как описать ошибки, чтобы это было красиво и правильно? 1️⃣ используем стандартизированные коды HTTP ✔️ 400 Bad Request — клиент что-то напутал; ✔️ 401 Unauthorized — нужна аутентификация; ✔️ 404 Not Found — не нашли, что искали; ✔️ 500 Internal Server Error — что-то сломалось на сервере. ➖➖➖ 2️⃣ добавляем дополнительную информацию в ответ Краткость, конечно, сестра таланта, но зачастую код-статуса не всегда информативен и нужна пояснительная бригада, поэтому в ответ можно добавить: ✔️ Уникальный ID ошибки (пусть коллеги ищут её в логах, а не в панике). Только не добавляйте это наружу; ✔️Чёткое описание проблемы; ✔️ Подсказку, как её исправить. Если такое возможно 😉 Например, { "status": 400, "error": "invalid_request", "message": "Поле 'email' обязательно.", "details": [ { "field": "email", "issue": "missing" } ], "timestamp": "2025-01-08T14:45:00Z", "trace_id": "abc123xyz" } ➖➖➖ 3️⃣ Придерживайтесь правил, которые приняты в компании. Формат ошибок должен быть единым для всех эндпоинтов и желательно для всех API. Это позволит поддерживать универсальность обработки этого добра ➖➖➖ Надеюсь с этим понятно, но, чтобы было нагляднее, как можно сделать, то вот парочка примеров от известных компаний: ✔️Google API: они добавляют у себя детальную информацию об ошибке, код и статус. { "error": { "code": 404, "message": "Requested entity was not found.", "status": "NOT_FOUND" } } ➖➖➖ ✔️ Stripe: они разделяют ошибки по типам и добавляют пояснение. { "error": { "type": "invalid_request_error", "message": "Missing required param: email" } } ➖➖➖ ✔️ GitHub: эти ребята немного борщат на мой взгляд, но подход интересный. Они добавляют ошибки с подсказками и ссылками на документацию. { "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ], "documentation_url": "https://docs.github.com/rest" } ➖➖➖ На этом пожалуй все. Делитесь, как у вас оформляют ошибки в компании?

Открыта предзапись на курс по интеграциям*: https://proanalitika.ru *вы гарантировано не пропустите старт продаж курса **вам напишет менеджер, когда будут открыты продажи #отзыв

Как перейти в системные аналитики из смежной профессии? Ребятушки, если вы или ваши друзья, хотите сменить профессию и влиться в ряды системных аналитиков, но не знаете, с чего начать, то этот пост для вас ♥️ Ниже будет пошаговый план, который поможет вам сократить путь и перейти из смежной сферы (тестирования, разработки, менеджмента) в системный анализ намного легче. Погнали 🚀 ➖➖➖ 1️⃣ БАЗА системного анализа Классика, о которой я говорю всегда! Для начала нужно разобраться, что вообще делает системный аналитик: ✔️ Сбор требований: пойми какие есть способы по сбору требований и как их можно фиксировать. ✔️ UML и BPMN: научись моделировать процессы и взаимодействия с помощью диаграмм. ✔️ Документирование требований: разберись, как описывать функциональные и нефункциональные требования. ✔️ Работа с API: научись читать спецификации (например, через Swagger) и тестировать их. Тестерам в этом плане повезло 😁 ✔️ Работа с Базами Данных: пойми, что такое реляционные и нереляционный БД и как с ними взаимодействовать. С чего начать? Изучи базовые статьи, посмотри бесплатные вебинары или записывайтесь на профильные курсы. Например, у меня есть курс «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API». Сейчас открыта предзапись на него ➖➖➖ 2️⃣ Используй текущий опыт Твои знания в смежной сфере — это крутой фундамент: ✔️ Тестировщики: вы уже знаете, как искать баги и работать с требованиями, просто добавьте навыки их создания. ✔️ Разработчики: вы понимаете логику работы систем и API, что облегчает переход. Остается подтянуть сбор требований и добавить знаний про управление ими. ✔️ Проджект менеджеры: вы умеете общаться с заказчиком и организовывать работу команды. Вам останется подтянуть техничку и вуаля 🙌🏻 Как прокачать эти навыки? Участвуй в задачах, которые связаны с аналитикой, даже на текущей должности. ➖➖➖ 3️⃣ Развивай soft skills Аналитик — это посредник между заказчиком, разработкой и тестированием, поэтому вам точно пригодятся такие навыки: ✔️ Навыки переговоров и презентаций, ✔️ Умение задавать правильные вопросы и расставлять приоритеты, ✔️ Грамотное документирование и структурирование информации. ➖➖➖ 4️⃣ Освой инструменты аналитика Системные аналитики работают с разными инструментами, но вот топ, который требуется практически везде: ✔️ Jira и Confluence для задач и документации, ✔️ PlantText или Draw.io для диаграмм, ✔️ Postman и Swagger для тестирования API. ➖➖➖ ⚡️⚡️⚡️ Просто изучение теории - это пустая трата времени. Тебе нужно найти возможность практиковаться: ✔️Участвуй в описании требований на текущем проекте, ✔️ Попробуй реализовать учебный проект, описывая систему от начала до конца на практических курсах. ✔️ Создай свой ПЭТ проект и тренируйся описывать его. ➖➖➖ 5️⃣ Подготовься к собеседованию На собесе я хочу конкретные примеры из опыта, поэтому подготовь: ✔️ Кейсы, где ты участвовал в описании требований или интеграций, ✔️ Документы, созданные тобой (UML-диаграммы, описания API), ✔️Примеры задач, которые ты решал. И да, прокачай свое резюме так, чтобы оно фокусировалось на аналитических задачах, а не на тех, которые ты делал в твоей текущей профессии. И главное — если решился стать аналитиком, то действуй и иди к своей цели. У тебя точно получится! Делись в комментариях своими историями, если ты успешно перешел из смежной профессии и стал системным аналитиком или задавай вопросы — разберём вместе 😘

#разборвопроса «Как чаще всего выяснять нефункциональные требования? Проговаривать каждый аспект? Или зачастую в проектах ctrl+С + ctrl+V?» С нефункциональными требованиями, по крайней мере, исходя из моего опыта, не все так очевидно. Чаще всего на проектах из-за темпа никто с НФТ не заморачивается, по крайней мере там, где компания создает продукт под себя. Что-то, где-то, кто-то собрал, но по факту, все делают Ctrl+C, Ctrl+V. Потому что у таких система по стандарту: ✔️ Время отклика до 3 секунд, ✔️ Доступность 99,9%, ✔️ Шифрование данных, ✔️ Логирование, например, в эластик. Однако, такой подход хоть и хорош тем, что мы не тратим время на уточнения деталей, однако, если всегда так делать то, когда-нибудь вам это обернется выстрелом в свою же ногу. ✖️ У вас упадет сервак в самый неподходящий момент из-за нагрузки, так как вы неправильно рассчитали пиковую; ✖️ Еще хуже, если придет кибер беза или юристы и скажет, что вы нарушили какой то закон, а виной этому будет просто привычка делать копипасту 🤷🏼‍♂️ Поэтому, когда собираете требования, то не забывайте про НФТ. Даже если горят сроки. ➖➖➖ ⚡️⚡️⚡️ Как же можно выяснить эти НФТ? ✔️ Обсуждаем с командой и интервьюируем стэкхолдеров Здесь уже нужен диалог: «А что будет, если пользователей станет 10 тысяч?» или «Какие устройства нужно поддерживать?» и тд ✔️ Используем чек-листы и стандарты Например, обязательно учитываем: ✔️ Производительность, ✔️ Надёжность, ✔️ Безопасность. ✔️Изучаем документацию, которая предоставляется заказчиком Особенно, если делаете что-то по какому-то приказу. Законы, ФЗ и все такое. ➖➖➖ А как у вас в проектах? Копипастите НФТ или собираете каждый раз с нуля?

Что почитать системному аналитику на новогодних каникулах? 📚 Ребят, я тут подумал, что пока идут новогодние праздники, можно заржаветь и обнулиться и в тоже время прям техничкой загружаться не очень хочется. Поэтому, вот топ-3 книги, которые вдохновят, прокачают ваши навыки и просто подарят приятные вечера! 1️⃣ "Проект Феникс" — Джин Ким IT-драма, где всё рушится, а герои пытаются всё спасти. 2️⃣ "Deadline: Роман о проектном управлении" — Том ДеМарко Классная книга о том, как сделать проекты с учетом жестких дедлайнов. 3️⃣ Цель, процесс непрерывного улучшения — Элияху Голдратт Что такое узкие горлышки, как их находить и исправлять. Читали что-то из этого? Делитесь впечатлениями в комментариях

Как понять сколько нужно будет времени на выполнение задачи, если ты новенький в компании? Думаю, многие из вас сталкивались с такой ситуацией: выходишь на новое место работы, начинаешь брать первые задачи, а в какие сроки ты их сделаешь - не знаешь. И в такие моменты возникает желание, сказать, что за спринт справлюсь, но, сразу огорчу вас на берегу, что если бы я такое услышал, то сильно бы усомнился в компетентности сотрудника, а это жирный минус на испытательном сроке. Поэтому, давайте расскажу, что я делаю, если сталкиваюсь с такой ситуацией: 1️⃣ Декомпозиция задачи Если задача понятная, то я ее разбираю на молекулы. Обычно, молекулы - это или подзадачи или чек-лист того, что нужно сделать. ✔️ Например, стоит задача: надо спроектировать API. Разбиваем на куски: ✔️ Разобраться в требованиях, ✔️ Спроектировать, ✔️ Прописать параметры, ✔️ Протестировать, ✔️ Задокументировать. Когда шаги понятны, становится проще понять, сколько времени каждый из них может занять. Если задача не понятная и декомпозировать не получается, то тут можно полагаться частично на свой опыт, но если у вас его немного, то это не поможет и поэтому можно перейти к следующему варианту. 2️⃣ Посовещаться с коллегами СА, командой или твоим ментором Серьёзно, не стесняйся задавать вопросы. Ты новый человек в команде и поэтому никто не ждёт, что ты сразу всё поймёшь. Коллеги знают, сколько времени уходило у них на подготовку задачи и могут подсказать срок или подскажут, где могут быть подводные камни. Однако, если коллеги подскажут из своего опыта срок, то именно его я бы не называл а сделал бы шаг 3 😉 3️⃣ Закладывать запас Если кажется, что справишься за 3 часа, или тебе эту цифру назвали коллеги, то заложи 4. Или даже 5. Это время на подумать, на покапать, на переделать, на посмотреть на задачу с другой стороны. Лучше сделать быстрее и попросить новую задачу, чем пообещать и не выполнить. И еще кое что! 4️⃣ Помнить, что ошибаться нормально Мы работаем в такой сфере, где куча нюансов, подводных камне и зависимостей, поэтому даже самые опытные и прожженные спецы, которые работают в компаниях годами могут давать неверные оценки из-за различных причин. ⚡️⚡️⚡️ Если сроки едут, то не «посыпай себе голову пеплом», а если уже появилось понимание, что нужно больше времени, НЕ ЖДИ и сообщи об этом команде. Это честно и показывает тебя с хорошей стороны ➖➖➖ Вот такие мысли на этот счет. А вы как даете оценку задачам? ➖➖➖ @proanalitica

Как не стрельнуть себе в ногу при описании API? Вчера смотрел доку на REST метод и увидел: в выходных параметрах поле PRICE, а в примере - значение 0. Что же здесь не так? Так то, что цена без копеек — это что-то из параллельной вселенной. На мой вопрос коллеге: «Почему так?», получил ответ: «Какая разница? JSON принимает number». С одной стороны, формально прав, ведь number действительно принимает и целые числа, и числа с плавающей точкой, но на практике — путь по скользкой дорожке, потому что она ведет к недопониманию: - Разработка увидит пример и сделает Ctrl+C + Ctrl+V, - Интеграторы подумают: "Аналитик указал integer, значит так и надо". Почему я уверен, что будет так? Потому что, когда-то в Альфе мы интегрировали UI-витрину с бэк-сервисами: фронт бежал вперёд, контракты были «на бумаге», в доке от бэка для поля с “неочевидными значениями” было написано число, а в примере - гордо красовался 0. Как честный человек, я так и заложил, а бизнес подтвердил, что будет целое число. И что по итогу? ▪️ Бэк внезапно заложил float, ▪️ На проде прилетает 12.34, ▪️ Фронт, конечно же, округляет до 12 и вызывает недоумение у заказчика, ▪️ Версию мобилки обновить быстро нельзя. Виноват ли фронт? Нет. Виноват ли бэк? Тоже нет. Просто спеки не дожали, детали не учли. ➖➖➖ Как избежать такие кейсы? 1️⃣ Примеры должны быть реалистичными - Если ожидаете float → показывайте 0.0, 12.99 - Если ожидаете integer → пусть будет 0, 42 2️⃣ Формат числового значения — must have! Не просто пишите number. Уточните формат, хотя бы number(19,2) 3️⃣ Минимизируйте двусмысленности Пример — это не просто иллюстрация, это часть спецификации, поэтому не скипайте даже самые тонкие нюансы. ✖️ Неправильный пример → неправильное восприятие → баги 4️⃣ Согласуйте правила в команде Документируйте Если параметр — число, всегда указываем его тип и пример. Например, везде где я работал, я всегда пишу int или float, а разрабы и так понимают, что в JSON будет number, но при этом им на берегу все очевидно из спеки. ➖➖➖ На что ещё стоит обратить внимание? ✔️0 — это не всегда float. Если ожидаете дробное, используйте 0.0. ✔️Ваши примеры — это ориентир для всех, кто будет работать с API. Фронт — не экстрасенс, ему важны детали. ✔️ Если вам кажется, что надо что-то изменить, то вам не кажется и надо менять. ✔️ Валидируйте свои спеки через других, так как может замылиться глаз. ➖➖➖ А что вы думаете на этот счет и как оформляете?

#разборвопроса Если в компании разработчики самостоятельно сразу пишут методы API в коде, то с чего стоит мне начать как аналитику, чтобы качественно проектировать и разработчики приняли нововведения? Частая ситуация, когда разрабы, как говорится «сами с усами»: все знают, все умеют, сами договорятся, сами разработают и вуаля. В целом, такой подход имеет место быть, так как он достаточно быстрый и если вам нужна скорость, а компания маленькая, то весьма оправданный. Однако, долго так работать я бы не стал, слишком много рисков: ✖️ Нет актуальной документации, ✖️ Отсутствует управление требованиями, ✖️ Увольнение разработчика или целиком команды и нет инфы вовсе. И итог у этого всего один - дальше будет больно, долго и дорого! Поэтому, если вас позвали в команду, где СА - это новый невиданный игрок, который еще и должен отобрать работу у светил разработки, то я бы не стал с ноги вламываться и менять процессы, а сделал следующее: 1️⃣ Разберись в текущем процессе, пойми как всё работает сейчас ✔️ Как разработчики пишут API? Есть ли устные договорённости, минимальная документация или они работают "по наитию"? ✔️ Какие проблемы возникают? Чаще всего это: - Несоответствие ожиданий фронтенда и бэкенда, - Изменения на поздних этапах разработки, - Неполная документация или её отсутствие, - Где я, как аналитик, могу быть полезен? Например, в структурировании данных, учёте бизнес-логики или создании стандартов? Когда процессы и правила игры в команде станут понятны, можно переходить к шагу 2. 2️⃣ Объясни, зачем это нужно Разработчики привыкли к своему процессу, поэтому важно показать, что проектирование API: ✔️ Экономит время В первую очередь время разработки, так как им не надо думать о бизнес-логике, ходить к бизнесам и с ними общаться. Они могут спокойно кодить и сосредоточиться на технологиях. ✔️ Упрощает взаимодействие Фронтенд, бэкенд, QA и аналитики работают по одному контракту, что снижает недопонимания. При этом, разработчиков уже не будут дергать QA, если у них вдруг возникнут вопросы. ✔️ Снимает рутину В документации уже есть структура, параметры и ответы — разработчикам не нужно об этом задумываться. Дальше, когда всем станет понятно, а зачем вообще СА что-то отдавать, то уже можно закатывать рукава и переходить к шагу 3. 3️⃣ Внедри удобный процесс Задача аналитика — не усложнить жизнь команды, а наоборот, упростить её. Начинаем с малого: ✔️ Шаблон проектирования API Создаем новые описания по единообразному шаблону. Например, как у меня на курсе и верифицируем его с командой, чтобы всем было понятно как с ним работать. ✔️ Обсуждение на грумминге Включи обсуждение API в командные встречи: - Какой функционал нужен? - Какие параметры будут передаваться? - Что API должно возвращать? Но что делать, если команда упирается рогом и никакую не соглашается? Тут только показывать делом и примером, что ты можешь и как можешь помочь, поэтому начни с одного примера. Покажи команде, как проектирование упрощает их работу: ✔️ Выбери простую задачу, ✔️ Вместе с разработчиками опиши API, ✔️ Убедись, что документация понятна всем: - фронтенду, - бэкенду, - QA, - и бизнесу ✔️ После завершения работы покажи результаты: - Меньше вопросов, - Нет доработок в процессе. Вуаля, они уже вдохновятся этим 🥂 А дальше, постепенно внедряй изменения, не пытайся сразу перестроить весь процесс, работай поэтапно Надеюсь, мои советы помогут тем, кто столкнулся с несговорчивыми разработчиками и они помогут растопить лед в их сердцах и помочь команде достигать крутых результатов 😉

Техническое интервью: что важно? Уже скоро состоится мок тех собес и я подумал, что как минимум один человек точно будет к нему точно готовиться, поэтому хочу поделиться своими мыслями на счет подготовки Погнали 🚀 Есть ощущение, что НАДО ВЫУЧИТЬ ВСЕ теоретические вопросы. 💾Но давайте по-честному: на собеседовании от вас не ждут энциклопедических знаний, а для меня, когда я провожу техсобес, главное — подход и умение работать с задачей. ➖➖➖ Кстати, как решать разные задачи на собесе можно подсмотреть по тегу #задача ➖➖➖ Вернемся к самому собесу На что я обычно смотрю? ✔️ Твое понимание роли СА Ты понимаешь роль СА, на что ты влияешь, где участвуешь, какие артефакты создаешь ✔️ Рассуждения и логика Например, я могу спросить: «Клиент хочет интеграцию с CRM, как ты это сделаешь?». Никто не ждёт идеального решения. Главное — показать свой ход мыслей: уточнить детали, подумать над ограничениями, предложить варианты. ✔️ Базовые технические знания REST API, SQL, UML, работа с БД, сбор и управление требованиями — это БАЗА. И поверь, никто не потребует, чтобы ты кодил или оптимизировал запросы. Достаточно объяснить, как это работает на уровне принципов. ✔️ Твои РЕАЛЬНЫЕ кейсы Это важно, потому что когда ты рассказываешь про свои кейсы или опыт работы, то при любой попытке пойти в глубь ты не посыпешься на вопросах. Например, «Расскажи про успешный проект» — это шанс блеснуть опытом. Подготовь истории, которые показывают твой вклад и решение сложностей. ➖➖➖ Что мне не особо интересно услышать? ⬅️ Я умею писать код Здорово, это твое преимущество, но фактически СА не пишет код, так как это задача разработчиков ⬅️ Оптимизация архитектуры системы Для этого есть архитекторы ⬅️ Знать всё о технологиях Для меня главное знать БАЗУ, а с технологиями можно разобраться за один день и дальше углубится, если это требуется ➖➖➖ Как подготовиться к собеседованию? ➡️ Освежи знания БАЗЫ, ➡️ Подготовь тезисно инфу про свой опыт работы И помни, что собес - это не односторонняя игра Я еще обращаю внимание, задает ли аналитик вопросы, уточняет ли детали в ходе беседы, так как это основной наш soft скилл, который отлично можно демонстрировать на собесах. ➖➖➖ А что вас больше всего пугает на интервью? Пишите, разберём вместе!