AI в работе системного аналитика
Думаю, каждый из вас слышал о нейронных сетях и, хотя бы раз пользовался ими. Генерить текст и картинки весело и просто, но удалось ли вам приспособить AI для повседневных задач? Сегодня рассказываю о сценариях использования, и как нейросети ускоряют мою работу.
На текущем проекте документация ведется по принципу Docs as a Code. В качестве текстового описания используется AsciiDoc, для генерации диаграмм PlantUML, а для апишек OpenAPI. На выходе у аналитика получается три артефакта: пошаговое описание процесса, диаграмма классов и Swagger. Теперь представьте, что в API содержится 50 параметров и все их нужно указать в Swagger. Реально, но очень скучно и долго. Для автоматизации этого удовольствия на помощь приходит ChatGPT.
Перед написанием спецификации я всегда тестирую запросы. Примеры прикладывает либо партнер, либо приходится формировать самостоятельно. Из примера запроса можно собрать целый OpenAPI всего одной командой. «Here is Json, convert it into OpenAPI schema». И документ в формате OpenAPI готов. Также ChatGPT можно попросить добавить описание и примеры параметров, но тут нужно быть осторожнее, чтобы не допустить несуразицу. Вложенность объектов, кстати, тоже учитывается.
То же самое можно сделать из диаграммы классов PlantUML. Подаете на вход диаграмму классов, на выходе получаете API схему. Обратный процесс также возможен, на основе Swagger можно сгенерить PlantUML.
Наконец, очень советую бесплатное расширение для IDEA Codeium, аналог GitHub Copilot. Незаменимая штука в работе аналитика, при создании того же OpenAPI. Плагин удерживает контекст и оперативно предлагает дополнения для документации, ускоряя работу.
А вы пользуетесь AI в работе? Расскажите об этом в комментариях.
Думаю, каждый из вас слышал о нейронных сетях и, хотя бы раз пользовался ими. Генерить текст и картинки весело и просто, но удалось ли вам приспособить AI для повседневных задач? Сегодня рассказываю о сценариях использования, и как нейросети ускоряют мою работу.
На текущем проекте документация ведется по принципу Docs as a Code. В качестве текстового описания используется AsciiDoc, для генерации диаграмм PlantUML, а для апишек OpenAPI. На выходе у аналитика получается три артефакта: пошаговое описание процесса, диаграмма классов и Swagger. Теперь представьте, что в API содержится 50 параметров и все их нужно указать в Swagger. Реально, но очень скучно и долго. Для автоматизации этого удовольствия на помощь приходит ChatGPT.
Перед написанием спецификации я всегда тестирую запросы. Примеры прикладывает либо партнер, либо приходится формировать самостоятельно. Из примера запроса можно собрать целый OpenAPI всего одной командой. «Here is Json, convert it into OpenAPI schema». И документ в формате OpenAPI готов. Также ChatGPT можно попросить добавить описание и примеры параметров, но тут нужно быть осторожнее, чтобы не допустить несуразицу. Вложенность объектов, кстати, тоже учитывается.
То же самое можно сделать из диаграммы классов PlantUML. Подаете на вход диаграмму классов, на выходе получаете API схему. Обратный процесс также возможен, на основе Swagger можно сгенерить PlantUML.
Наконец, очень советую бесплатное расширение для IDEA Codeium, аналог GitHub Copilot. Незаменимая штука в работе аналитика, при создании того же OpenAPI. Плагин удерживает контекст и оперативно предлагает дополнения для документации, ускоряя работу.
А вы пользуетесь AI в работе? Расскажите об этом в комментариях.
🔥14👍5
TheAPIfirstWorldPostman.pdf
14.5 MB
Щупаем Postman
Нашел необычный промо материал от команды Postman.
Комикс рассказывает о том, для чего нужны API, и какие возможности предоставляет Postman.
Внезапно, там не только отправка запросов, а, например, встроенный гит.
Плюс частенько сталкиваюсь с ситуацией, когда начинающий аналитик на практике ни разу не отправлял запросы и не представляет, как работать с API. Прикладываю документацию на сервис постмана, который позволяет опробовать различные методы.
А вы знали, что в постмане можно импортировать и сохранять curl?
Или добавлять скрипты к запросам, например, для сохранения токена в переменную и использования ее в дальнейших запросах?
Наберем 25 реакций и я расскажу как это делать)
Нашел необычный промо материал от команды Postman.
Комикс рассказывает о том, для чего нужны API, и какие возможности предоставляет Postman.
Внезапно, там не только отправка запросов, а, например, встроенный гит.
Плюс частенько сталкиваюсь с ситуацией, когда начинающий аналитик на практике ни разу не отправлял запросы и не представляет, как работать с API. Прикладываю документацию на сервис постмана, который позволяет опробовать различные методы.
А вы знали, что в постмане можно импортировать и сохранять curl?
Или добавлять скрипты к запросам, например, для сохранения токена в переменную и использования ее в дальнейших запросах?
Наберем 25 реакций и я расскажу как это делать)
🔥29👍10⚡3🥴1
Процесс собеседования. Практика
Постепенно завершаем цикл статей о процессе собеседования на позицию системного аналитика. На очереди практических блок. Чаще всего он выделен в отдельное интервью в крупных компаниях. За час-полтора вам предложат решить различные задачи, которые можно объединить в три категории, сегодня как раз разберем их. Кстати, не забывайте, что о наличии или отсутствии отдельного практического блока можно узнать еще при первом знакомстве с рекрутером
Задача на SQL. Наиболее популярное задание, проверяющее соответствующий скилл. Чаще всего аналитика просят написать SELECT с использованием JOIN из одной или нескольких таблиц, применив агрегатные функции и группировку. Пример реальной задачи: Выведи информацию о Supplier и Category по продуктам, у которых цена выше средней. Для выполнения использовать ресурс
Стоит упомянуть, что задачи могут быть и сложнее, но чаще всего об этом будет явно указано в вакансии. Например, требование о знании оконных функций.
Моделирование предметной области. Здесь чаще всего аналитика просят спроектировать какую-либо диаграмму, показав процесс или предметную область. Мне доставался и BPMN, и Sequence, и ER. В зависимости от уровня вакансии компания может вообще не привязываться к какой-либо нотации, а просто проверить системное мышление кандидата. Пример задачи на собеседовании в желтый банк звучит как: Спроектируй логическую модель данных для интернет-магазина по продаже книг. Или другой пример: Спроектируй Sequence диаграмму для процесса оплаты в банковском приложении.
Задача на работу с API. Здесь открывается пространство для творчества. Самая простая задача, найти ошибки в JSON или XML. Вопрос поинтереснее может звучать так: Спроектируй endpoint для интернет-магазина по продаже книг.
Обращаю внимание, что и в этом и в прошлом примерах присутствуют элементы системного дизайна. Чем больше вопросов аналитик задаст интервьюеру и чем сильнее сузится область работы, тем проще будет. Вы же понимаете, что за час нереально сделать адекватный API? Без должного уровня абстракции не обойтись.
В комментариях предлагаю делиться своим опытом прохождение практического интервью. Будет интересно почитать, какие необычные задачи доставались вам.
#база
Постепенно завершаем цикл статей о процессе собеседования на позицию системного аналитика. На очереди практических блок. Чаще всего он выделен в отдельное интервью в крупных компаниях. За час-полтора вам предложат решить различные задачи, которые можно объединить в три категории, сегодня как раз разберем их. Кстати, не забывайте, что о наличии или отсутствии отдельного практического блока можно узнать еще при первом знакомстве с рекрутером
Задача на SQL. Наиболее популярное задание, проверяющее соответствующий скилл. Чаще всего аналитика просят написать SELECT с использованием JOIN из одной или нескольких таблиц, применив агрегатные функции и группировку. Пример реальной задачи: Выведи информацию о Supplier и Category по продуктам, у которых цена выше средней. Для выполнения использовать ресурс
Стоит упомянуть, что задачи могут быть и сложнее, но чаще всего об этом будет явно указано в вакансии. Например, требование о знании оконных функций.
Моделирование предметной области. Здесь чаще всего аналитика просят спроектировать какую-либо диаграмму, показав процесс или предметную область. Мне доставался и BPMN, и Sequence, и ER. В зависимости от уровня вакансии компания может вообще не привязываться к какой-либо нотации, а просто проверить системное мышление кандидата. Пример задачи на собеседовании в желтый банк звучит как: Спроектируй логическую модель данных для интернет-магазина по продаже книг. Или другой пример: Спроектируй Sequence диаграмму для процесса оплаты в банковском приложении.
Задача на работу с API. Здесь открывается пространство для творчества. Самая простая задача, найти ошибки в JSON или XML. Вопрос поинтереснее может звучать так: Спроектируй endpoint для интернет-магазина по продаже книг.
Обращаю внимание, что и в этом и в прошлом примерах присутствуют элементы системного дизайна. Чем больше вопросов аналитик задаст интервьюеру и чем сильнее сузится область работы, тем проще будет. Вы же понимаете, что за час нереально сделать адекватный API? Без должного уровня абстракции не обойтись.
В комментариях предлагаю делиться своим опытом прохождение практического интервью. Будет интересно почитать, какие необычные задачи доставались вам.
#база
👍8👌4
Лайфхаки Postman
Прошлый пост вам зашел сильно! Поэтому, как и обещал, рассказываю о работе с curl и переменными в постмане.
1) Postman позволяет очень удобно работать с curl. Допустим у нас есть запрос:
Возможен и обратный процесс. Представим, что вы составили запрос и хотите добавить его в документацию или поделиться с кем-нибудь. Конечно, всегда можно использовать постман-коллекции, но также можно конвертировать его в curl. Тыкаем на значок «кода» и в выпадающем списке выбираем curl.
2) Postman позволяет работать с переменным. Одним из сценариев использования является сохранение токена и обращение к нему в последующих запросах, без постоянного ctrl+C, ctrl+V. Для создания переменных тыкаем «Environments», затем «+» и создаем новое окружение, в котором будут храниться наши переменные. Наконец, внутри окружения задаем переменную.
Теперь в запросе переходим во вкладку «Tests» (не забываем предварительно изменить окружение на только что созданное) и пишем две строчки:
Во всех последующих запросах обращаемся к переменной, на время действия токена она будет валидна.
В комментариях предлагаю делиться своими фишками, упрощающими работу с Postman.
P.S. В тему работы с API, недавно выходила статья о документации, заценить можно здесь.
Прошлый пост вам зашел сильно! Поэтому, как и обещал, рассказываю о работе с curl и переменными в постмане.
1) Postman позволяет очень удобно работать с curl. Допустим у нас есть запрос:
curl --location --request POST 'https://example.ru/lead-api/lead/check-phone' \В боковом меню проходим по пути File—>Import и просто вставляем имеющийся curl. Запрос добавится целиком. Вам останется только отправить его.
--header 'Authorization: Bearer ***' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'phone=78005553535'
Возможен и обратный процесс. Представим, что вы составили запрос и хотите добавить его в документацию или поделиться с кем-нибудь. Конечно, всегда можно использовать постман-коллекции, но также можно конвертировать его в curl. Тыкаем на значок «кода» и в выпадающем списке выбираем curl.
2) Postman позволяет работать с переменным. Одним из сценариев использования является сохранение токена и обращение к нему в последующих запросах, без постоянного ctrl+C, ctrl+V. Для создания переменных тыкаем «Environments», затем «+» и создаем новое окружение, в котором будут храниться наши переменные. Наконец, внутри окружения задаем переменную.
Теперь в запросе переходим во вкладку «Tests» (не забываем предварительно изменить окружение на только что созданное) и пишем две строчки:
var jsonData=JSON.parse(responseBody) – парсим ответpostman.setEnvironmentVariable("access_token", jsonData.access_token) – записываем параметр «access_token» в одноименную переменную.Во всех последующих запросах обращаемся к переменной, на время действия токена она будет валидна.
В комментариях предлагаю делиться своими фишками, упрощающими работу с Postman.
P.S. В тему работы с API, недавно выходила статья о документации, заценить можно здесь.
👍4
Процесс собеседования. Подходы к ведению интервью
С точки зрения кандидата, мы разобрали процесс интервью вдоль и поперек. Научились грамотно продавать себя и отвечать на каверзные вопросы. А что же технический интервьюер? Кто знает, вдруг когда-нибудь и вам придется принимать перспективных аналитиков к себе в компанию. Сегодня смотрим два разных подхода к ведению интервью.
«Стандартное» интервью. Интервью, каким вы себе его представляете. Часик-полтора, плотно наполненные теорией разного сорта. Топ-100 вопросов на позицию системного аналитика. Именно то, что мы с вами так тщательно разбирали последнее время. Да, это скучный подход, но все еще наиболее распространенный на рынке. Молодые интервьюеры начинают именно с него, и нельзя их винить в том, что они неправы. Выделение ключевых тем для системного аналитика и подготовка вопросов по ним, помогают сформировать структуру в голове. Другой разговор, что после десятка повторений, вопросы и ответы считываются на автомате и не приносят удовольствия. В этот момент мозг генерирует идеи, и тогда рождается второй подход.
Интервью, после которого хочется жить. Когда устал спрашивать однотипные вопросы и хочется радовать себя и кандидатов. В таком случае стоит включить воображение. А что если спрашивать аналитика исключительно по его опыту? Затронуть все интересующие темы, через вопросы а-ля: «А как вы писали документацию/Как валидировали требования/Почему именно такие способы….» Но тут и кандидат должен рассказать о прошлом опыте так, чтобы была возможность задать вопросы. Или другой пример – построить интервью через практический кейс. Не спрашивать «какие техники сбора требований знаешь», а «представь у тебя есть целевая группа, как будешь собирать требования». Я проводил такие интервью, когда мы начинали со сбора требований в БА блоке и заканчивали моделированием таблиц базы данных в СА. По итогу, кандидат и я были в восторге он проведенного времени.
В качестве заключения, хочется еще раз подчеркнуть, что от классного интервью выигрывают обе стороны. Вы, как интервьюер, получаете практические ответы, а не сухую теорию. Кандидат же, запоминает компанию и будет более лоялен на следующих этапах. Не ленитесь делать лучшие собеседования!
#база
С точки зрения кандидата, мы разобрали процесс интервью вдоль и поперек. Научились грамотно продавать себя и отвечать на каверзные вопросы. А что же технический интервьюер? Кто знает, вдруг когда-нибудь и вам придется принимать перспективных аналитиков к себе в компанию. Сегодня смотрим два разных подхода к ведению интервью.
«Стандартное» интервью. Интервью, каким вы себе его представляете. Часик-полтора, плотно наполненные теорией разного сорта. Топ-100 вопросов на позицию системного аналитика. Именно то, что мы с вами так тщательно разбирали последнее время. Да, это скучный подход, но все еще наиболее распространенный на рынке. Молодые интервьюеры начинают именно с него, и нельзя их винить в том, что они неправы. Выделение ключевых тем для системного аналитика и подготовка вопросов по ним, помогают сформировать структуру в голове. Другой разговор, что после десятка повторений, вопросы и ответы считываются на автомате и не приносят удовольствия. В этот момент мозг генерирует идеи, и тогда рождается второй подход.
Интервью, после которого хочется жить. Когда устал спрашивать однотипные вопросы и хочется радовать себя и кандидатов. В таком случае стоит включить воображение. А что если спрашивать аналитика исключительно по его опыту? Затронуть все интересующие темы, через вопросы а-ля: «А как вы писали документацию/Как валидировали требования/Почему именно такие способы….» Но тут и кандидат должен рассказать о прошлом опыте так, чтобы была возможность задать вопросы. Или другой пример – построить интервью через практический кейс. Не спрашивать «какие техники сбора требований знаешь», а «представь у тебя есть целевая группа, как будешь собирать требования». Я проводил такие интервью, когда мы начинали со сбора требований в БА блоке и заканчивали моделированием таблиц базы данных в СА. По итогу, кандидат и я были в восторге он проведенного времени.
В качестве заключения, хочется еще раз подчеркнуть, что от классного интервью выигрывают обе стороны. Вы, как интервьюер, получаете практические ответы, а не сухую теорию. Кандидат же, запоминает компанию и будет более лоялен на следующих этапах. Не ленитесь делать лучшие собеседования!
#база
👍11
Как пройти собеседование на позицию системного аналитика?
Вчера подошел к концу цикл статей о процессе собеседования. Мы разобрали каждый этап по кирпичику. Для всех, кто присоединился к нам недавно, дублирую ссылки на посты в хронологическом порядке:
Введение. Что из себя представляет интервью?
Самопрезентация
Бизнес анализ
Системный анализ
Что спросить после технического интервью?
Что еще важно знать, чтобы быть эффективнее?
Практическая секция
Рекомендации для интервьюеров
Сохраняйте, чтобы не потерять!
Вчера подошел к концу цикл статей о процессе собеседования. Мы разобрали каждый этап по кирпичику. Для всех, кто присоединился к нам недавно, дублирую ссылки на посты в хронологическом порядке:
Введение. Что из себя представляет интервью?
Самопрезентация
Бизнес анализ
Системный анализ
Что спросить после технического интервью?
Что еще важно знать, чтобы быть эффективнее?
Практическая секция
Рекомендации для интервьюеров
Сохраняйте, чтобы не потерять!
🔥19
Паттерны реализации микросервисной архитектуры
Один из популярных вопросов на собеседовании уровня Senior. Паттернов много, и чем больше кандидат сможет назвать и объяснить, тем больше очков в копилку получит. Сегодня разбираем некоторые из них.
Паттерн декомпозиции на микросервисы:
- Декомпозиция по бизнес возможностям - паттерн предполагает определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них
- Декомпозиция по поддоменам (DDD) - паттерн основан на концепции DDD
Паттерн рефакторинга для перехода на микросервисы
- Душитель (Strangler) - паттерн предполагает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы.
- Слой защиты от повреждений (Anti-corruption layer) - паттерн предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба.
Паттерн управления данными в микросервисах
- Saga - паттерн предназначен для управления распределенными транзакциями
- CQRS - паттерн предлагает отделить изменение данных (Command) от чтения данных (Query)
- API композиция – паттерн предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти
- Event Sourcing - паттерн, предполагает сохранение не объектов, а их состояний
- База данных на микросервис
Паттерн взаимодействия между сервисами
- Обмен сообщениями
- Удаленный вызов процедур
Паттерн коммуникации с внешними сервисами
- API Gateway - паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента
- BFF - аналогичен Gateway, разница в том, что вместо одной точки входа вводит несколько шлюзов для каждого типа клиента
Паттерн мониторинга состояния микросервисов
- Логи
- Метрики
- Журналирование
- Трассировка
- Отслеживание исключений
- Проверка работоспособности API
Паттерн построения пользовательского интерфейса
- На сервере
- На клиенте
Паттерн развертывания микросервисов
- Один сервис на хост
- Множество сервисов на хост
А с какими паттернами вам приходилось сталкиваться в работе?
P.S. В комментариях найдете графическую схему описанных паттернов
Один из популярных вопросов на собеседовании уровня Senior. Паттернов много, и чем больше кандидат сможет назвать и объяснить, тем больше очков в копилку получит. Сегодня разбираем некоторые из них.
Паттерн декомпозиции на микросервисы:
- Декомпозиция по бизнес возможностям - паттерн предполагает определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них
- Декомпозиция по поддоменам (DDD) - паттерн основан на концепции DDD
Паттерн рефакторинга для перехода на микросервисы
- Душитель (Strangler) - паттерн предполагает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы.
- Слой защиты от повреждений (Anti-corruption layer) - паттерн предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба.
Паттерн управления данными в микросервисах
- Saga - паттерн предназначен для управления распределенными транзакциями
- CQRS - паттерн предлагает отделить изменение данных (Command) от чтения данных (Query)
- API композиция – паттерн предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти
- Event Sourcing - паттерн, предполагает сохранение не объектов, а их состояний
- База данных на микросервис
Паттерн взаимодействия между сервисами
- Обмен сообщениями
- Удаленный вызов процедур
Паттерн коммуникации с внешними сервисами
- API Gateway - паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента
- BFF - аналогичен Gateway, разница в том, что вместо одной точки входа вводит несколько шлюзов для каждого типа клиента
Паттерн мониторинга состояния микросервисов
- Логи
- Метрики
- Журналирование
- Трассировка
- Отслеживание исключений
- Проверка работоспособности API
Паттерн построения пользовательского интерфейса
- На сервере
- На клиенте
Паттерн развертывания микросервисов
- Один сервис на хост
- Множество сервисов на хост
А с какими паттернами вам приходилось сталкиваться в работе?
P.S. В комментариях найдете графическую схему описанных паттернов
❤18👍3⚡2
У меня специфический опыт. Как сменить работу?
Мы с вами много говорим о системном анализе, совершенно забывая, что помимо распространенных решений, есть узкие, вендорные. Существуют аналитики 1С, консультанты SAP, специалисты по SalesForce и другим «коробочным» решениям. Сразу скажу, я ничего не имею против вендоров, если вам нравится быть экспертом в узкой нише, это прекрасно. Тем более я сам начинал с SAP. А что же делать, если не нравится и хочется уйти в «обычное ИТ»? Когда вместо транзакций и транспортов хочется интеграций? Давайте разбираться.
Стоит оговориться, что чем дольше вы занимаетесь вендорным решением, тем больше времени крадете у самого себя. Задачи и рабочие процессы «коробки» сильно отличаются от современной разработки. Условный SAP, это всегда доработка существующего решения под нужды заказчика. Чаще всего, самые простые настройки выполняются прямо из интерфейса программы и требуют знаний конкретного софта. Мне и моим знакомым было крайне тяжело уходить с вендорного решения, потому что знания SAP (или софта любого другого вендора) никак не помогут при прохождении собеседований. Если только вы не ищите соответствующую вакансию. Как первая работа без опыта, для понимания ИТ – супер, но не больше чем на полгода-год.
Другая сторона, вы уже проработали 5-10 лет под крылом вендора, что же делать? Активно учить технологии, требуемые на собеседовании и пытаться сопоставить их с ранее решенными задачами. Летом, мы занимались с Максимом, который проработал в SAP более 15 лет. Мы разобрали его достижения, обсудили реальные боевые задачи и оказалось, что у него есть реальный опыт интеграций, работы с брокерами и т.д., только в SAP это работает и называется немного иначе. Вместе мы структурировали информацию, и научились правильно ее подавать. Поэтому выход есть.
Резюмируя:
- Работа у вендоров дает узкий опыт, релевантный только для этих вендоров;
- Как первый опыт – ок, но не больше, чем на год;
- Если засиделись, ищите сходства в вашей работе и тем, что требуется на рынке;
- Не можете сами, обратитесь к ментору.
А как вы относитесь к работе с вендорными решениями? Был ли такой опыт?
Мы с вами много говорим о системном анализе, совершенно забывая, что помимо распространенных решений, есть узкие, вендорные. Существуют аналитики 1С, консультанты SAP, специалисты по SalesForce и другим «коробочным» решениям. Сразу скажу, я ничего не имею против вендоров, если вам нравится быть экспертом в узкой нише, это прекрасно. Тем более я сам начинал с SAP. А что же делать, если не нравится и хочется уйти в «обычное ИТ»? Когда вместо транзакций и транспортов хочется интеграций? Давайте разбираться.
Стоит оговориться, что чем дольше вы занимаетесь вендорным решением, тем больше времени крадете у самого себя. Задачи и рабочие процессы «коробки» сильно отличаются от современной разработки. Условный SAP, это всегда доработка существующего решения под нужды заказчика. Чаще всего, самые простые настройки выполняются прямо из интерфейса программы и требуют знаний конкретного софта. Мне и моим знакомым было крайне тяжело уходить с вендорного решения, потому что знания SAP (или софта любого другого вендора) никак не помогут при прохождении собеседований. Если только вы не ищите соответствующую вакансию. Как первая работа без опыта, для понимания ИТ – супер, но не больше чем на полгода-год.
Другая сторона, вы уже проработали 5-10 лет под крылом вендора, что же делать? Активно учить технологии, требуемые на собеседовании и пытаться сопоставить их с ранее решенными задачами. Летом, мы занимались с Максимом, который проработал в SAP более 15 лет. Мы разобрали его достижения, обсудили реальные боевые задачи и оказалось, что у него есть реальный опыт интеграций, работы с брокерами и т.д., только в SAP это работает и называется немного иначе. Вместе мы структурировали информацию, и научились правильно ее подавать. Поэтому выход есть.
Резюмируя:
- Работа у вендоров дает узкий опыт, релевантный только для этих вендоров;
- Как первый опыт – ок, но не больше, чем на год;
- Если засиделись, ищите сходства в вашей работе и тем, что требуется на рынке;
- Не можете сами, обратитесь к ментору.
А как вы относитесь к работе с вендорными решениями? Был ли такой опыт?
🔥12👍5💯2
Топ-50 вопросов на позицию «Бизнес аналитика»
Наткнулся на полезный ресурс, где собраны различные вопросы по направлениям. В числе прочих фигурирует бизнес анализ. Прикладываю их ниже. От себя добавлю, что это исключительно бизнесовые вопросы. Все, что касается работы системного аналитика (архитектура, интеграции, аутентификация и тд) здесь не затрагивается.
В списке собраны вопросы как по софтам, так и по хардам
1. Какие техники выявления требований бы использовал для решения проблемы
2. Расскажи о своем опыте
3. Расскажи о себе
4. Как считаешь, при найме БА компании важны больше soft skills или hard skills
5. Что нравится больше всего в бизнес-анализе
6. Чем занимается бизнес-аналитик в продуктовой команде
7. Какой главный принцип проведения брейншторма
8. Чем отличается Product Owner от бизнес-аналитика
9. Твой совет для улучшения уровня взаимодействия разработчиков и бизнес-аналитика
10. Что такое сторипоинты (Story Points)
11. Какие методы оценки задач есть кроме Story Points
12. В чем отличие Waterfall от Agile
13. Какие минусы есть у Agile
14. Какие минусы есть у Scrum
15. Что думаешь об использовании опросников
16. Как бы написал User Story, приведи пример
17. Что такое требования
18. Какие виды требований знаешь
19. Что такое нефункциональные требования (НФТ)
20. Какие существуют методы сбора требований
21. Как валидируешь и верифицируешь требования
22. В чем разница между валидацией и верификацией требований
23. Что такое use case
24. Что такое варианты использования
25. Для чего нужна приоритезация
26. Какие методы приоритезации существуют
27. Что такое change management
28. Что самое важное в change management
29. Что такое User Story
30. Что такое критерии приёмки (acceptance criteria)
31. Что такое User Story Mapping
32. Что такое декомпозиция User Story
33. Как работает техника оценки user story - invest
34. Пришла новая задача (проблема), как будешь её решать
35. Как обеспечить прозрачную коммуникацию с клиентами
36. Что делать, если заказчик не доволен реализацией решения
37. Как определить самую неприоритетную задачу в текущем спринте
38. Как определить самую не приоритетную задачу в текущем спринте
39. Что будешь делать, если спринт начинается через 3 дня, а у твоей команды пустой бэклог
40. Что будешь делать, если team-lead говорит о невозможности реализации фичи
41. В какой момент возникает ответственность бизнес-аналитика
42. Как связана работа бизнес-аналитика с конечными пользователями (не с заказчиками)
43. Сколько проектов одновременно может вести аналитик
44. В каком виде будешь представлять заказчику промежуточные результаты
45. Что нужно делать, чтобы исключить непредусмотренные corner cases (корнер кейсы)
46. Какой жизненный цикл (SDLC) у продукта
47. Что из себя представляет документ SRS (Software requirements specification)
48. Какие разделы есть в SRS
49. Какую документацию создавал
50. Для чего нужно прототипирование интерфейсов
51. Какие инструменты используются для прототипирования интерфейсов
52. Что такое UML
53. Что такое BPMN-нотация
54. В каких ситуациях идти со списком вопросов на встречу не эффективно
Какие из них встречались вам?
Наткнулся на полезный ресурс, где собраны различные вопросы по направлениям. В числе прочих фигурирует бизнес анализ. Прикладываю их ниже. От себя добавлю, что это исключительно бизнесовые вопросы. Все, что касается работы системного аналитика (архитектура, интеграции, аутентификация и тд) здесь не затрагивается.
В списке собраны вопросы как по софтам, так и по хардам
1. Какие техники выявления требований бы использовал для решения проблемы
2. Расскажи о своем опыте
3. Расскажи о себе
4. Как считаешь, при найме БА компании важны больше soft skills или hard skills
5. Что нравится больше всего в бизнес-анализе
6. Чем занимается бизнес-аналитик в продуктовой команде
7. Какой главный принцип проведения брейншторма
8. Чем отличается Product Owner от бизнес-аналитика
9. Твой совет для улучшения уровня взаимодействия разработчиков и бизнес-аналитика
10. Что такое сторипоинты (Story Points)
11. Какие методы оценки задач есть кроме Story Points
12. В чем отличие Waterfall от Agile
13. Какие минусы есть у Agile
14. Какие минусы есть у Scrum
15. Что думаешь об использовании опросников
16. Как бы написал User Story, приведи пример
17. Что такое требования
18. Какие виды требований знаешь
19. Что такое нефункциональные требования (НФТ)
20. Какие существуют методы сбора требований
21. Как валидируешь и верифицируешь требования
22. В чем разница между валидацией и верификацией требований
23. Что такое use case
24. Что такое варианты использования
25. Для чего нужна приоритезация
26. Какие методы приоритезации существуют
27. Что такое change management
28. Что самое важное в change management
29. Что такое User Story
30. Что такое критерии приёмки (acceptance criteria)
31. Что такое User Story Mapping
32. Что такое декомпозиция User Story
33. Как работает техника оценки user story - invest
34. Пришла новая задача (проблема), как будешь её решать
35. Как обеспечить прозрачную коммуникацию с клиентами
36. Что делать, если заказчик не доволен реализацией решения
37. Как определить самую неприоритетную задачу в текущем спринте
38. Как определить самую не приоритетную задачу в текущем спринте
39. Что будешь делать, если спринт начинается через 3 дня, а у твоей команды пустой бэклог
40. Что будешь делать, если team-lead говорит о невозможности реализации фичи
41. В какой момент возникает ответственность бизнес-аналитика
42. Как связана работа бизнес-аналитика с конечными пользователями (не с заказчиками)
43. Сколько проектов одновременно может вести аналитик
44. В каком виде будешь представлять заказчику промежуточные результаты
45. Что нужно делать, чтобы исключить непредусмотренные corner cases (корнер кейсы)
46. Какой жизненный цикл (SDLC) у продукта
47. Что из себя представляет документ SRS (Software requirements specification)
48. Какие разделы есть в SRS
49. Какую документацию создавал
50. Для чего нужно прототипирование интерфейсов
51. Какие инструменты используются для прототипирования интерфейсов
52. Что такое UML
53. Что такое BPMN-нотация
54. В каких ситуациях идти со списком вопросов на встречу не эффективно
Какие из них встречались вам?
🔥7👍2
Популярные стили архитектуры API
Сегодня говорим о подходах к реализации API. Очевидно, что большинство специалистов знакомы с REST и SOAP, но есть и другие технологии. Привожу некоторые из них, о каждой можно почитать подробнее по приложенным ссылкам. Графический материал, как обычно, в комментариях.
1. gRPC: Высокопроизводительный, не зависящий от языка фреймворк удаленного вызова процедур (RPC) для эффективного взаимодействия между распределенными системами, часто используемый в архитектурах микросервисов.
2. SOAP: Протокол для обмена структурированной информацией при реализации веб-сервисов, известный своими строгими стандартами и форматом сообщений на основе XML.
3. GraphQL: Язык запросов и среда выполнения для API, позволяющая клиентам запрашивать только те данные, которые им необходимы, что уменьшает избыточную и недостаточную выборку данных.
4. Webhook: Механизм взаимодействия в реальном времени, при котором приложение отправляет HTTP POST-запросы на заранее определенный URL-адрес для уведомления и запуска действий в другой системе.
5. REST: Representational State Transfer - архитектурный стиль проектирования сетевых приложений, использующий стандартные методы HTTP (GET, POST, PUT, DELETE) для манипулирования ресурсами.
6. WebSocket: Протокол, обеспечивающий двунаправленную связь между клиентом и сервером в реальном времени через одно долговременное соединение. Идеально подходит для приложений, требующих обновления данных с малой задержкой, таких как чат или игры.
Сегодня говорим о подходах к реализации API. Очевидно, что большинство специалистов знакомы с REST и SOAP, но есть и другие технологии. Привожу некоторые из них, о каждой можно почитать подробнее по приложенным ссылкам. Графический материал, как обычно, в комментариях.
1. gRPC: Высокопроизводительный, не зависящий от языка фреймворк удаленного вызова процедур (RPC) для эффективного взаимодействия между распределенными системами, часто используемый в архитектурах микросервисов.
2. SOAP: Протокол для обмена структурированной информацией при реализации веб-сервисов, известный своими строгими стандартами и форматом сообщений на основе XML.
3. GraphQL: Язык запросов и среда выполнения для API, позволяющая клиентам запрашивать только те данные, которые им необходимы, что уменьшает избыточную и недостаточную выборку данных.
4. Webhook: Механизм взаимодействия в реальном времени, при котором приложение отправляет HTTP POST-запросы на заранее определенный URL-адрес для уведомления и запуска действий в другой системе.
5. REST: Representational State Transfer - архитектурный стиль проектирования сетевых приложений, использующий стандартные методы HTTP (GET, POST, PUT, DELETE) для манипулирования ресурсами.
6. WebSocket: Протокол, обеспечивающий двунаправленную связь между клиентом и сервером в реальном времени через одно долговременное соединение. Идеально подходит для приложений, требующих обновления данных с малой задержкой, таких как чат или игры.
🔥14👍5
Когда пора увольняться?
Тема наиболее актуальная для меня, поскольку нахожусь в процессе перехода в новую компанию. Много общался с коллегами, которые терпят и страдают, но не уходят. Причин, как обычно, множество, но основная – боязнь неизвестности. Ведь «здесь» все предельно ясно, а «там» придется осваиваться заново. Но я не встречал ни одного человека, кто бы пожалел о смене работы. Итак, когда стоит уходить?
Спустя 1-1.5 года. Именно столько длится жизненный цикл начинающего аналитика в одной компании. Затем происходит потеря навыков. Задачки постепенно становятся рутинными, каждая новая – повторение предыдущей. Сколько интеграций нужно сделать, чтобы научиться проектировать базы данных? Вы можете возразить: «Так ведь можно попросить руководителя подкинуть новых челленджей». И я абсолютно согласен, но помимо квалификации, вы теряете еще и в деньгах. Рынок дает сильно больше, чем текущий работодатель. И даже в случае повышения в рамках компании, разница с рыночным предложением останется существенная. Если бы я был не прав, то историй с ростом в х4 не было бы.
При возникновении красных флагов. У каждого они свои, но если работа сильно гнетет вас, и вы не чувствуете себя счастливым, то стоит сменить компанию. Это могут быть переработки, негативные отношения с коллегами, отсутствие помощи, и даже задачи, которые вам неинтересны. Конечно, первым делом стоит поговорить и решить проблему самостоятельно, но это получается не всегда. Из личного опыта, на прошлой работе из меня очень хотели сделать руководителя проектов. Я несколько раз разговаривал и объяснял, что управление сроками и вот это все, мне просто неинтересно, хочется углубляться в технику. Тогда директор ответил: «Ну, мы не можем просто так снять с тебя эту ответственность. Ты же руководитель проектов, какие способы выхода из этой ситуации видишь?» Тогда я нашел решение. В новой компании.
«Кажется я засиделся». При возникновении такого чувства, я бы тоже менял работу. Все может быть отлично: задач много, коллеги отзывчивые, руководитель хвалит. Но мысль об упущенных возможностях не дает покоя каждый день. Возможно вам нужно поменять род деятельности, а возможно вы взяли из компании все, что могли и теперь только отдаете. Опять пример из прошлого опыта. За первый год работы я понял роль аналитика и поучаствовал в проекте внедрения ERP системы (если хотите услышать подробную историю, накидайте реакций). Получил огромное количество опыта и сильно прокачал скиллы. Было ощущение, что больше здесь ловить нечего, но я остался еще на полтора года. За это время спроектировал 1 API и занимался тем, что больше мне не пригодилось. Ну и стоило ли оно того?
В качестве промежуточного итога хочу еще раз подчеркнуть, что вы никому ничего не должны. Выход на новую работу – это волнительный, но важный шаг в карьере любого аналитика.
#увольнение
Тема наиболее актуальная для меня, поскольку нахожусь в процессе перехода в новую компанию. Много общался с коллегами, которые терпят и страдают, но не уходят. Причин, как обычно, множество, но основная – боязнь неизвестности. Ведь «здесь» все предельно ясно, а «там» придется осваиваться заново. Но я не встречал ни одного человека, кто бы пожалел о смене работы. Итак, когда стоит уходить?
Спустя 1-1.5 года. Именно столько длится жизненный цикл начинающего аналитика в одной компании. Затем происходит потеря навыков. Задачки постепенно становятся рутинными, каждая новая – повторение предыдущей. Сколько интеграций нужно сделать, чтобы научиться проектировать базы данных? Вы можете возразить: «Так ведь можно попросить руководителя подкинуть новых челленджей». И я абсолютно согласен, но помимо квалификации, вы теряете еще и в деньгах. Рынок дает сильно больше, чем текущий работодатель. И даже в случае повышения в рамках компании, разница с рыночным предложением останется существенная. Если бы я был не прав, то историй с ростом в х4 не было бы.
При возникновении красных флагов. У каждого они свои, но если работа сильно гнетет вас, и вы не чувствуете себя счастливым, то стоит сменить компанию. Это могут быть переработки, негативные отношения с коллегами, отсутствие помощи, и даже задачи, которые вам неинтересны. Конечно, первым делом стоит поговорить и решить проблему самостоятельно, но это получается не всегда. Из личного опыта, на прошлой работе из меня очень хотели сделать руководителя проектов. Я несколько раз разговаривал и объяснял, что управление сроками и вот это все, мне просто неинтересно, хочется углубляться в технику. Тогда директор ответил: «Ну, мы не можем просто так снять с тебя эту ответственность. Ты же руководитель проектов, какие способы выхода из этой ситуации видишь?» Тогда я нашел решение. В новой компании.
«Кажется я засиделся». При возникновении такого чувства, я бы тоже менял работу. Все может быть отлично: задач много, коллеги отзывчивые, руководитель хвалит. Но мысль об упущенных возможностях не дает покоя каждый день. Возможно вам нужно поменять род деятельности, а возможно вы взяли из компании все, что могли и теперь только отдаете. Опять пример из прошлого опыта. За первый год работы я понял роль аналитика и поучаствовал в проекте внедрения ERP системы (если хотите услышать подробную историю, накидайте реакций). Получил огромное количество опыта и сильно прокачал скиллы. Было ощущение, что больше здесь ловить нечего, но я остался еще на полтора года. За это время спроектировал 1 API и занимался тем, что больше мне не пригодилось. Ну и стоило ли оно того?
В качестве промежуточного итога хочу еще раз подчеркнуть, что вы никому ничего не должны. Выход на новую работу – это волнительный, но важный шаг в карьере любого аналитика.
#увольнение
👍26🔥16❤5🤔1
Как уволиться красиво?
Продолжаем разбирать процесс увольнения. Вы все-таки решили уйти, но как сделать это максимально грамотно, оставив хорошие отношения с работодателем? Ведь ИТшечка – это узкий кружок, где все всех знают. Что же нужно, чтобы быть красавчиком?подписаться на канал (Не)Системная аналитика
Предупредить работодателя заранее. Решение об уходе принимается явно не за две недели. Скорее всего, вы обдумывали это на протяжении нескольких месяцев. Если точка невозврата пройдена, и вы однозначно решили для себя, что будете искать другое место – лучше заранее предупредить работодателя. На прошлой работе я сигнализировал о своих проблемах за несколько месяцев до ухода. Мы пытались найти решение, но так и ни к чему не пришли. Переходя в стадию активного поиска я в явном виде сказал, что смотрю вакансии на рынке. Поэтому, когда работодатель увидел мое заявление, это не было для него шоком. Другая ситуация, когда вас схантили и предложили кратно больше текущего заработка. Здесь «плавный уход» не представляется возможным.
Завершить дела перед уходом. С момента написания заявления начинается двухнедельный срок, в течение которого необходимо закрыть все текущие задачи. С точки зрения работодателя правильным шагом является вывод вас из ключевых проектов и передача дополнительных активностей. За это время можно написать инструкции или актуализировать документацию. Объяснить новичкам узкие моменты и передать знания. Худшее, что может произойти, это оставленная задача, которую кроме вас никто не знает, как делать. Считай, работу можно начинать заново.
Продолжать выполнять задачи и поддерживать связь с коллегами. Велик соблазн забить на все и отдыхать две недели. Да, никакой ответственности не будет, но, мне кажется, стоит оставаться профессионалом. Темп выполняемой работы может быть снижен, но качество превыше всего. В конце концов, кто знает, может вам придется поработать с этими людьми вновь?
А какие проблемы были у вас при увольнении? Расскажите об этом в комментариях
#увольнение
Продолжаем разбирать процесс увольнения. Вы все-таки решили уйти, но как сделать это максимально грамотно, оставив хорошие отношения с работодателем? Ведь ИТшечка – это узкий кружок, где все всех знают. Что же нужно, чтобы быть красавчиком?
Предупредить работодателя заранее. Решение об уходе принимается явно не за две недели. Скорее всего, вы обдумывали это на протяжении нескольких месяцев. Если точка невозврата пройдена, и вы однозначно решили для себя, что будете искать другое место – лучше заранее предупредить работодателя. На прошлой работе я сигнализировал о своих проблемах за несколько месяцев до ухода. Мы пытались найти решение, но так и ни к чему не пришли. Переходя в стадию активного поиска я в явном виде сказал, что смотрю вакансии на рынке. Поэтому, когда работодатель увидел мое заявление, это не было для него шоком. Другая ситуация, когда вас схантили и предложили кратно больше текущего заработка. Здесь «плавный уход» не представляется возможным.
Завершить дела перед уходом. С момента написания заявления начинается двухнедельный срок, в течение которого необходимо закрыть все текущие задачи. С точки зрения работодателя правильным шагом является вывод вас из ключевых проектов и передача дополнительных активностей. За это время можно написать инструкции или актуализировать документацию. Объяснить новичкам узкие моменты и передать знания. Худшее, что может произойти, это оставленная задача, которую кроме вас никто не знает, как делать. Считай, работу можно начинать заново.
Продолжать выполнять задачи и поддерживать связь с коллегами. Велик соблазн забить на все и отдыхать две недели. Да, никакой ответственности не будет, но, мне кажется, стоит оставаться профессионалом. Темп выполняемой работы может быть снижен, но качество превыше всего. В конце концов, кто знает, может вам придется поработать с этими людьми вновь?
#увольнение
👍15🤨2
Коды состояния HTTP
Сегодня разбираем коды состояния HTTP по группам. Выделяют следующие:
Информационные ответы (100 - 199)
Успешные ответы (200 - 299)
Сообщения о перенаправлении (300 - 399)
Ответы об ошибках клиента (400 - 499)
Ответы об ошибках сервера (500 - 599)
Ниже приведены наиболее часто встречающиеся коды состояния
1. Информационные (1xx):
- 100 Continue
2. Успешные (2xx):
- 200 OK
- 201 Created
- 204 No Content
3. Перенаправление (3xx):
- 301 Moved Permanently
- 302 Found
4. Ошибка клиента (4xx):
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
5. Ошибка сервера (5xx):
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
А вы знаете для чего нужен код состояния 418 I'm a teapot?
Сегодня разбираем коды состояния HTTP по группам. Выделяют следующие:
Информационные ответы (100 - 199)
Успешные ответы (200 - 299)
Сообщения о перенаправлении (300 - 399)
Ответы об ошибках клиента (400 - 499)
Ответы об ошибках сервера (500 - 599)
Ниже приведены наиболее часто встречающиеся коды состояния
1. Информационные (1xx):
- 100 Continue
2. Успешные (2xx):
- 200 OK
- 201 Created
- 204 No Content
3. Перенаправление (3xx):
- 301 Moved Permanently
- 302 Found
4. Ошибка клиента (4xx):
- 400 Bad Request
- 401 Unauthorized
- 403 Forbidden
- 404 Not Found
5. Ошибка сервера (5xx):
- 500 Internal Server Error
- 502 Bad Gateway
- 503 Service Unavailable
А вы знаете для чего нужен код состояния 418 I'm a teapot?
👍13❤2
Популярные заблуждения, мешающие смене работы
Самый главный стоп-фактор перед увольнением – совесть. Можно рационально взвесить все «за» и «против», но справиться с внутренними противоречиями бывает тяжело. Разбираем популярные заблуждения, мешающие смене работы:
«Если я уйду, я предам компанию и коллектив. Компания вложила в меня силы и средства. А команда без меня не справится». Из банального – без тебя еще как справятся и незаменимых людей нет. И о каком предательстве может идти речь в рамках трудовых отношений? Да, компания вложила в тебя ресурсы и вырастила (в случае с джунами), но, проработав в ней некоторое время, ты вернул все «долги». Работодатель дал возможность набраться опыта, взамен ты дал возможность заработать на себе. Представим ситуацию, что у компании закончились деньги. Будет ли она переживать во время твоего увольнения: «Ой, мы ведь его предаем, он ведь так хорошо работал»? Бонусом, почитайте комментарии под одним из предыдущих постов об увольнении. Ребята поделились своим опытом.
«На текущем месте я знаком с процессами и командой. На новой работе все новое и страшное, вдруг я не приживусь?» Мы разбирали синдром самозванца в одном из прошлых постов. Да, смена работы – это всегда некий риск и тут важно взвесить все плюсы и минусы. А еще присмотреться вокруг – если коллеги и начальство отзывались о тебе только положительно и хвалили, возможно найти общий язык с людьми не так уж и сложно для тебя?
«У меня испытательный срок в новой компании и мне здесь не нравится. Как же я уйду? Ведь компания меня онбордила, выдавала доступы и вводила в процессы?» Испытательный срок для того и нужен, чтобы проверить, как вы приживетесь. Работодатель проверяет вас, но и вы проверяете работодателя. И нет ничего страшного, чтобы сказать: «Ребята, мне кажется мы не сработаемся», и спокойно уйти. Добавлять ли этот опыт в CV? Можно добавить и честно рассказать, почему не смог сработаться. А можно просто докинуть месяц-два к предыдущему месту работы.
«Меня и так стабильно повышают, зачем уходить?» Тебя повышают ровно настолько, чтобы ты не ушел. Рынок может дать сильно больше. Пример из собственного опыта, на первой работе за год меня повысили с 45к до 70к, за второй год с 70к до 110к. Маячило очередное «повышение» до 120к, но я ушел в другую компанию на 200к. Щупайте рынок и ищите максимально выгодное предложение.
«Я не готов менять работу сейчас. Требования высокие, мне нужно еще полгодика поучиться.» Сейчас дефицит системных аналитиков на рынке. Возможно ты уже подходишь для многих вакансий, но просто не сходил на собеседование. Идеальный вариант – выйти на рынок, узнать, что реально спрашивают на собеседованиях и повторять именно эти темы. Учиться и параллельно искать работу. Так время будет распределено эффективно.
На этом завершаем цикл статей об увольнении. Остальные доступы по тегу #увольнение
А если вы только ищите работу и не собираетесь увольняться, рекомендую цикл статей о процессе собеседования на позицию системного аналитика.
Самый главный стоп-фактор перед увольнением – совесть. Можно рационально взвесить все «за» и «против», но справиться с внутренними противоречиями бывает тяжело. Разбираем популярные заблуждения, мешающие смене работы:
«Если я уйду, я предам компанию и коллектив. Компания вложила в меня силы и средства. А команда без меня не справится». Из банального – без тебя еще как справятся и незаменимых людей нет. И о каком предательстве может идти речь в рамках трудовых отношений? Да, компания вложила в тебя ресурсы и вырастила (в случае с джунами), но, проработав в ней некоторое время, ты вернул все «долги». Работодатель дал возможность набраться опыта, взамен ты дал возможность заработать на себе. Представим ситуацию, что у компании закончились деньги. Будет ли она переживать во время твоего увольнения: «Ой, мы ведь его предаем, он ведь так хорошо работал»? Бонусом, почитайте комментарии под одним из предыдущих постов об увольнении. Ребята поделились своим опытом.
«На текущем месте я знаком с процессами и командой. На новой работе все новое и страшное, вдруг я не приживусь?» Мы разбирали синдром самозванца в одном из прошлых постов. Да, смена работы – это всегда некий риск и тут важно взвесить все плюсы и минусы. А еще присмотреться вокруг – если коллеги и начальство отзывались о тебе только положительно и хвалили, возможно найти общий язык с людьми не так уж и сложно для тебя?
«У меня испытательный срок в новой компании и мне здесь не нравится. Как же я уйду? Ведь компания меня онбордила, выдавала доступы и вводила в процессы?» Испытательный срок для того и нужен, чтобы проверить, как вы приживетесь. Работодатель проверяет вас, но и вы проверяете работодателя. И нет ничего страшного, чтобы сказать: «Ребята, мне кажется мы не сработаемся», и спокойно уйти. Добавлять ли этот опыт в CV? Можно добавить и честно рассказать, почему не смог сработаться. А можно просто докинуть месяц-два к предыдущему месту работы.
«Меня и так стабильно повышают, зачем уходить?» Тебя повышают ровно настолько, чтобы ты не ушел. Рынок может дать сильно больше. Пример из собственного опыта, на первой работе за год меня повысили с 45к до 70к, за второй год с 70к до 110к. Маячило очередное «повышение» до 120к, но я ушел в другую компанию на 200к. Щупайте рынок и ищите максимально выгодное предложение.
«Я не готов менять работу сейчас. Требования высокие, мне нужно еще полгодика поучиться.» Сейчас дефицит системных аналитиков на рынке. Возможно ты уже подходишь для многих вакансий, но просто не сходил на собеседование. Идеальный вариант – выйти на рынок, узнать, что реально спрашивают на собеседованиях и повторять именно эти темы. Учиться и параллельно искать работу. Так время будет распределено эффективно.
На этом завершаем цикл статей об увольнении. Остальные доступы по тегу #увольнение
А если вы только ищите работу и не собираетесь увольняться, рекомендую цикл статей о процессе собеседования на позицию системного аналитика.
🔥17❤7