Каналу месяц!
(Не)Системная аналитика появилась ровно месяц назад, 16 августа. За это время мы с вами плавно преодолели отметку в 150 человек! Для меня это огромная цифра, спасибо каждому кто подписался. Мы пилили посты и мемы, делились полезным и заряжались на успех. Я очень рад, что смог найти единомышленников среди вас, надеюсь, что вам интересно. Впереди большие планы, бэклог заполнен идеями, поэтому без контента вас не оставлю.
Я создавал канал, преследуя 2 цели: собрать ответы на популярные вопросы с консультаций, кстати, если кому-то нужна помощь, обращайтесь. А также использовать тг, как способ разнообразить рутинные будни. Мы же все понимаем, что айтишная работа не самая захватывающая) Рекомендую попробовать завести блог - это не страшно.
Еще раз спасибо, что подписаны на меня! Лучшая благодарность за контент – рассказать о канале знакомым аналитикам, вдруг им тоже понравится.
Обнял, приподнял,
Андрей
З.Ы. В комментариях принимаю идеи по улучшению канала. Чего не хватает, а что можно убрать?
(Не)Системная аналитика появилась ровно месяц назад, 16 августа. За это время мы с вами плавно преодолели отметку в 150 человек! Для меня это огромная цифра, спасибо каждому кто подписался. Мы пилили посты и мемы, делились полезным и заряжались на успех. Я очень рад, что смог найти единомышленников среди вас, надеюсь, что вам интересно. Впереди большие планы, бэклог заполнен идеями, поэтому без контента вас не оставлю.
Я создавал канал, преследуя 2 цели: собрать ответы на популярные вопросы с консультаций, кстати, если кому-то нужна помощь, обращайтесь. А также использовать тг, как способ разнообразить рутинные будни. Мы же все понимаем, что айтишная работа не самая захватывающая) Рекомендую попробовать завести блог - это не страшно.
Еще раз спасибо, что подписаны на меня! Лучшая благодарность за контент – рассказать о канале знакомым аналитикам, вдруг им тоже понравится.
Обнял, приподнял,
Андрей
З.Ы. В комментариях принимаю идеи по улучшению канала. Чего не хватает, а что можно убрать?
🔥11❤🔥4👍4⚡1💔1
Дайджест полезного #5
ДИСКЛЕЙМЕР: Автор канала не является дипломированном психологом и предлагает решения, основываясь исключительно на житейском опыте. Если вы чувствуете проблемы, с которыми не можете справиться, обратитесь к специалистам.
Сегодняшняя подборка содержит статьи околоайтишной тематики. Проблема, которая наиболее часто встречается у ребят на консультациях – синдром самозванца. Кто-то сомневается в своих способностях и боится попробовать новое, а кто-то прямым текстом говорит: «Да, у меня синдром самозванца». Хотя никакого отношения к медицине «синдром» не имеет. Тем не менее ловите ссылки на три полезные статьи, еще раз убеждающие вас в том, что вы все сможете!
1) «Что такое синдром самозванца и почему необязательно с ним бороться». Статья нетологии, где детально расписываются признаки и разновидности синдрома, а также приводятся советы о том, как побороть свои страхи. Классифицируя виды «самозванцев» поймал себя на мысли, что во мне уживаются все из них.
2) «Синдром самозванца. Как обрести уверенность и начать действовать». Чуть более глубокое чтиво, раскрывающее такие понятия как «эксперт» и «псевдоэксперт». В статье рассматриваются популярные искажения, и возможные корни проблемы. После прочтения картинка в голове вырисовывается четче.
3) «Синдром самозванца в IT: почему возникает и как его преодолеть». Ну и доходим до профессии. Статья является компиляцией того, что описано в пунктах 1 и 2, только с уклоном в ИТ тематику. Поскольку нам отовсюду говорят, что квалифицированный специалист должен постоянно развиваться и прокачивать скилл, очень легко выгореть и загнаться. Не надо так!
В качестве послесловия хочу еще раз напомнить о том, что беречь кукушку невероятно важно. Понимание сути проблемы сильно облегчит дальнейший путь. Идеальных не бывает, ошибаться и пробовать – это нормально. Если вам страшно откликаться на вакансии, проходить собеседования, вливаться в коллектив и прочее, то возможно стоит хотя бы раз попробовать это сделать, а не сидеть и тревожиться. Вдруг все не так тяжело, как рисует мозг.
ДИСКЛЕЙМЕР: Автор канала не является дипломированном психологом и предлагает решения, основываясь исключительно на житейском опыте. Если вы чувствуете проблемы, с которыми не можете справиться, обратитесь к специалистам.
Сегодняшняя подборка содержит статьи околоайтишной тематики. Проблема, которая наиболее часто встречается у ребят на консультациях – синдром самозванца. Кто-то сомневается в своих способностях и боится попробовать новое, а кто-то прямым текстом говорит: «Да, у меня синдром самозванца». Хотя никакого отношения к медицине «синдром» не имеет. Тем не менее ловите ссылки на три полезные статьи, еще раз убеждающие вас в том, что вы все сможете!
1) «Что такое синдром самозванца и почему необязательно с ним бороться». Статья нетологии, где детально расписываются признаки и разновидности синдрома, а также приводятся советы о том, как побороть свои страхи. Классифицируя виды «самозванцев» поймал себя на мысли, что во мне уживаются все из них.
2) «Синдром самозванца. Как обрести уверенность и начать действовать». Чуть более глубокое чтиво, раскрывающее такие понятия как «эксперт» и «псевдоэксперт». В статье рассматриваются популярные искажения, и возможные корни проблемы. После прочтения картинка в голове вырисовывается четче.
3) «Синдром самозванца в IT: почему возникает и как его преодолеть». Ну и доходим до профессии. Статья является компиляцией того, что описано в пунктах 1 и 2, только с уклоном в ИТ тематику. Поскольку нам отовсюду говорят, что квалифицированный специалист должен постоянно развиваться и прокачивать скилл, очень легко выгореть и загнаться. Не надо так!
В качестве послесловия хочу еще раз напомнить о том, что беречь кукушку невероятно важно. Понимание сути проблемы сильно облегчит дальнейший путь. Идеальных не бывает, ошибаться и пробовать – это нормально. Если вам страшно откликаться на вакансии, проходить собеседования, вливаться в коллектив и прочее, то возможно стоит хотя бы раз попробовать это сделать, а не сидеть и тревожиться. Вдруг все не так тяжело, как рисует мозг.
Telegram
(Не)Системная аналитика by Андрей Царев
«А вдруг я не смогу?» или синдром самозванца не дремлет
Примерно так звучит самое распространенное опасение моих менти. Ситуация: ты классный системный аналитик, получаешь Х денег и решаешь сменить работу. Читаешь вакансию на миддла – подходишь, читаешь…
Примерно так звучит самое распространенное опасение моих менти. Ситуация: ты классный системный аналитик, получаешь Х денег и решаешь сменить работу. Читаешь вакансию на миддла – подходишь, читаешь…
❤5🔥3🤝2
Процесс собеседования. Вопросы после технического интервью
Поздравляю, вы прошли техническое интервью. Складно отвечали на вопросы бизнес-анализа, применяли знания по интеграциям в секции системного анализа, и, наконец, интервьюер говорит: «У меня все, теперь готов ответить на ваши вопросы». Около половины кандидатов в этот момент виснет и не знает, что можно спросить. Вот примерный перечень классных вопросов, показывающих вас как заинтересованного аналитика.
1) «Чем мне предстоит заниматься ежедневно? Что входит в мои обязанности? Расскажи примерный день системного аналитика». Этой пачкой вопросов вы показываете заинтересованность, плюс сразу же более-менее понимаете фронт работ. Да, есть описание вакансии и рассказ рекрутера, но они, как правило, очень абстрактные. Здесь же, человек, который реально занят в компании, сможет рассказать о боевых задачах. Ответ в духе: «Ну, у нас вообще-то не было никогда системного аналитика, и мы его берем, потому что это круто и модно» - плохой. Если только позиция не предполагает выстраивание аналитики с нуля, но там и компенсация соответствующая.
2) «Каким образом выстроены рабочие процессы? По какой методологии работаете?» Нужны для представления о том, как будет проходить работа. Можно ли решать задачи в конвейерном режиме или же придется постоянно сидеть на звонках, обсуждая каждый чих. Четкий и описанный флоу, а также его понимание, сильно упрощает и ускоряет работу. Если вам ответят: «Каждая задача уникальна и требует тщательного обсуждения со всей командой», знайте, в таком месте лучше не работать.
3) «Есть ли план развития сотрудников? И план развития компании в целом?» Вопрос нужен, чтобы с порога понимать, будет ли возможность прокачивать экспертизу и развиваться. Работодатель может не иметь внутреннего портала с курсами, но компенсировать внешнее обучение. Спрашивая подобное, с большой долей вероятности вам дополнительно расскажут о процессе пересмотра зп. Плохой же ответ звучит как: «У нас настолько интересные задачи, что сотрудники развиваются, просто решая их». Читай его как: «Через 3 месяца тебе станет скучно, но мы ничего с этим не сделаем».
4) Вопросы, которые волнуют вас по прошлому опыту. Например, переработки, KPI и прочее. Узнавайте обо всем, что доставляло неудобства ранее, дабы не нарваться на те же грабли. Например, на прошлом месте работы премиальная часть моей зп (аналитика) зависела от SLA тикетов поддержки. Естественно я первую очередь решал запросы пользователей, а не занимался тем, что мне действительно нравится.
В качестве заключения, хочу напомнить, что задавать вопросы крайне важно. А еще каждый вопрос уместно спрашивать в подходящей ситуации. Например, на встрече с командой не стоит разговаривать о зп, а об удаленке можно узнать еще при первом контакте.
В комментариях рассказывайте, какие интересные вопросы задаете вы?
#база
Поздравляю, вы прошли техническое интервью. Складно отвечали на вопросы бизнес-анализа, применяли знания по интеграциям в секции системного анализа, и, наконец, интервьюер говорит: «У меня все, теперь готов ответить на ваши вопросы». Около половины кандидатов в этот момент виснет и не знает, что можно спросить. Вот примерный перечень классных вопросов, показывающих вас как заинтересованного аналитика.
1) «Чем мне предстоит заниматься ежедневно? Что входит в мои обязанности? Расскажи примерный день системного аналитика». Этой пачкой вопросов вы показываете заинтересованность, плюс сразу же более-менее понимаете фронт работ. Да, есть описание вакансии и рассказ рекрутера, но они, как правило, очень абстрактные. Здесь же, человек, который реально занят в компании, сможет рассказать о боевых задачах. Ответ в духе: «Ну, у нас вообще-то не было никогда системного аналитика, и мы его берем, потому что это круто и модно» - плохой. Если только позиция не предполагает выстраивание аналитики с нуля, но там и компенсация соответствующая.
2) «Каким образом выстроены рабочие процессы? По какой методологии работаете?» Нужны для представления о том, как будет проходить работа. Можно ли решать задачи в конвейерном режиме или же придется постоянно сидеть на звонках, обсуждая каждый чих. Четкий и описанный флоу, а также его понимание, сильно упрощает и ускоряет работу. Если вам ответят: «Каждая задача уникальна и требует тщательного обсуждения со всей командой», знайте, в таком месте лучше не работать.
3) «Есть ли план развития сотрудников? И план развития компании в целом?» Вопрос нужен, чтобы с порога понимать, будет ли возможность прокачивать экспертизу и развиваться. Работодатель может не иметь внутреннего портала с курсами, но компенсировать внешнее обучение. Спрашивая подобное, с большой долей вероятности вам дополнительно расскажут о процессе пересмотра зп. Плохой же ответ звучит как: «У нас настолько интересные задачи, что сотрудники развиваются, просто решая их». Читай его как: «Через 3 месяца тебе станет скучно, но мы ничего с этим не сделаем».
4) Вопросы, которые волнуют вас по прошлому опыту. Например, переработки, KPI и прочее. Узнавайте обо всем, что доставляло неудобства ранее, дабы не нарваться на те же грабли. Например, на прошлом месте работы премиальная часть моей зп (аналитика) зависела от SLA тикетов поддержки. Естественно я первую очередь решал запросы пользователей, а не занимался тем, что мне действительно нравится.
В качестве заключения, хочу напомнить, что задавать вопросы крайне важно. А еще каждый вопрос уместно спрашивать в подходящей ситуации. Например, на встрече с командой не стоит разговаривать о зп, а об удаленке можно узнать еще при первом контакте.
В комментариях рассказывайте, какие интересные вопросы задаете вы?
#база
Telegram
(Не)Системная аналитика by Андрей Царев
Процесс собеседования. Бизнес анализ
Итак, с презентацией себя разобрались. Вы складно рассказали о своем опыте, произвели первое положительное впечатление, теперь настало время проверить харды. Вообще интервью делится на 2 типа: компания может спрашивать…
Итак, с презентацией себя разобрались. Вы складно рассказали о своем опыте, произвели первое положительное впечатление, теперь настало время проверить харды. Вообще интервью делится на 2 типа: компания может спрашивать…
🔥6❤4👍3🌭1
Ребята, привет)
Улетаю сегодня в отпуск, поэтому посты могут выходить нерегулярно. Мемов, само собой, накидал)
Вернусь в начале октября, не теряйте.
Обнял ❤️
Улетаю сегодня в отпуск, поэтому посты могут выходить нерегулярно. Мемов, само собой, накидал)
Вернусь в начале октября, не теряйте.
Обнял ❤️
👍12🔥6
Процесс собеседования. Что еще важно знать, чтобы быть эффективнее?
Итак, вы максимально подготовились к техническому интервью. Поболтали с HR, изучили бизнес и системный анализ, придумали пачку интересных вопросов и готовы побеждать. Как вдруг вас посещает мысль: «А может есть что-то еще, что я не учел?» Некие тайные знания, неочевидная информация, обладая которой можно стать лучшим кандидатом. Еще как есть! Делюсь с вами несколькими советами-напоминаниями, которые относятся к процессу интервью в целом.
1) Собеседования и реальная работа практически не имеют ничего общего. Запомните это. Большинство интервью проверяют теоретические знания, а практика отходит на второй план. Работа, в большинстве своей, предполагает решение конкретных, узких задач. Вы можете на автомате клепать синхронные интеграции по имеющейся документации, укладывая их в стандартные процессы. Но это не поможет, если на собеседовании вас спросят об аутентификации, асинхроне, нереляционных БД и тому подобное. Можно быть мощным практиком, но без базы и понимания, почему мы делаем так, а не иначе, собес не пройти. Из этого вытекает второй совет…
2) К собеседованиям нужно всегда готовиться. Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK. Глобально это не поставит на вас крест, но точно даст работодателю повод предложить меньше денег. И даже со структурированной информацией в голове, опыт важно правильно подать. Поэтому стоит…
3) Научиться продавать себя как высококвалифицированного специалиста. На собеседовании обе стороны немного лукавят: компания может умолчать об устаревшем стеке или объеме техдолга, но и вы не должны говорить все как есть. Например, SQL вы используете раз в месяц, чтобы проверить наличие данных в базе. На вопрос работодателя: «Владеете ли вы SQL?» справедливо ответить: «Да, владею, использую в работе, строю отчеты». И тут два варианта событий: вам либо предложат решить задачу, которую вы осилите (ведь вы же готовились и повторили синткасис), либо ответят: «Ну, окэй» и пойдут дальше. Всегда подавайте себя чуточку лучше, чем вы есть на самом деле, если возникнут сомнения – вас тут же проверят. Не нужно закапывать самого себя. И наконец последний совет…
4) Всегда торгуйтесь за оффер. Получив долгожданное предложение о работе очень просто сказать: «Да, я на все согласен». Но подождите, есть вероятность, что работодатель сможет дать еще больше. Не бойтесь торговаться. Наиболее простой способ написать что-то в духе: «Спасибо за предложение, вы мне очень понравились, но у меня есть другое предложение, и я не могу выбрать, где мне будет лучше. Есть ли возможность улучшить условия?» Оффер не отзовут и на вас не посмотрят криво. В худшем случае скажут: «Извините, мы не можем изменить условия». Тогда просто примите как есть, и останетесь при своем. Лично мне удавалось за одно сообщение поднять предложение на 25к, как будто вам тоже стоит попробовать.
Отчасти мне понятно, почему многие кандидаты не могут рассказывать о своих достижениях и бояться попросить больше. Мое поколение учили не выделяться, и быть скромным. Но интервью — это точно не то место, где нужно сдерживать себя (в адекватных пределах). Не стесняйтесь грамотно продавать себя и все получится.
А какие советы по интервью можете дать вы?
#база
Итак, вы максимально подготовились к техническому интервью. Поболтали с HR, изучили бизнес и системный анализ, придумали пачку интересных вопросов и готовы побеждать. Как вдруг вас посещает мысль: «А может есть что-то еще, что я не учел?» Некие тайные знания, неочевидная информация, обладая которой можно стать лучшим кандидатом. Еще как есть! Делюсь с вами несколькими советами-напоминаниями, которые относятся к процессу интервью в целом.
1) Собеседования и реальная работа практически не имеют ничего общего. Запомните это. Большинство интервью проверяют теоретические знания, а практика отходит на второй план. Работа, в большинстве своей, предполагает решение конкретных, узких задач. Вы можете на автомате клепать синхронные интеграции по имеющейся документации, укладывая их в стандартные процессы. Но это не поможет, если на собеседовании вас спросят об аутентификации, асинхроне, нереляционных БД и тому подобное. Можно быть мощным практиком, но без базы и понимания, почему мы делаем так, а не иначе, собес не пройти. Из этого вытекает второй совет…
2) К собеседованиям нужно всегда готовиться. Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK. Глобально это не поставит на вас крест, но точно даст работодателю повод предложить меньше денег. И даже со структурированной информацией в голове, опыт важно правильно подать. Поэтому стоит…
3) Научиться продавать себя как высококвалифицированного специалиста. На собеседовании обе стороны немного лукавят: компания может умолчать об устаревшем стеке или объеме техдолга, но и вы не должны говорить все как есть. Например, SQL вы используете раз в месяц, чтобы проверить наличие данных в базе. На вопрос работодателя: «Владеете ли вы SQL?» справедливо ответить: «Да, владею, использую в работе, строю отчеты». И тут два варианта событий: вам либо предложат решить задачу, которую вы осилите (ведь вы же готовились и повторили синткасис), либо ответят: «Ну, окэй» и пойдут дальше. Всегда подавайте себя чуточку лучше, чем вы есть на самом деле, если возникнут сомнения – вас тут же проверят. Не нужно закапывать самого себя. И наконец последний совет…
4) Всегда торгуйтесь за оффер. Получив долгожданное предложение о работе очень просто сказать: «Да, я на все согласен». Но подождите, есть вероятность, что работодатель сможет дать еще больше. Не бойтесь торговаться. Наиболее простой способ написать что-то в духе: «Спасибо за предложение, вы мне очень понравились, но у меня есть другое предложение, и я не могу выбрать, где мне будет лучше. Есть ли возможность улучшить условия?» Оффер не отзовут и на вас не посмотрят криво. В худшем случае скажут: «Извините, мы не можем изменить условия». Тогда просто примите как есть, и останетесь при своем. Лично мне удавалось за одно сообщение поднять предложение на 25к, как будто вам тоже стоит попробовать.
Отчасти мне понятно, почему многие кандидаты не могут рассказывать о своих достижениях и бояться попросить больше. Мое поколение учили не выделяться, и быть скромным. Но интервью — это точно не то место, где нужно сдерживать себя (в адекватных пределах). Не стесняйтесь грамотно продавать себя и все получится.
А какие советы по интервью можете дать вы?
#база
❤15👍6
Как правильно задавать вопросы?
Частенько ко мне на консультации приходят с запросом: «А как понять, что я хорошо работаю?» Казалось бы, ответ очевиден - если проходишь испытательный срок и тебе не подсвечивают очевидных проблем, значит все прекрасно. Но отсутствие обратной связи, где аналитику прямо говорят - «ты красавчик», сильно бьет по самооценке. Вообще, компании заинтересованы в сохранении сотрудников и должны сами выстраивать процессы таким образом, чтобы новичку было максимально комфортно. Правда, как обычно, в какой момент что-то идёт не так, и ты работаешь, работаешь, работаешь, а понимания того, все ли нормально, так и нет.
Первым советом в такой ситуации будет - «не бояться спрашивать и разговаривать». Большинство рабочих вопросов решаются на месте, и чем думать: «А как бы мне узнать хорошо ли я сделал задачу или нет?», лучше просто спросить. В ИТ, а тем более аналитике, не очень любят молчаливых. Не нужно молчать о проблемах или о возможности сорвать сроки. Если рассказать о своих трудностях, то вас точно поймут и предложат помощь.
Другой страх: «Вдруг я спрошу вопрос, а он окажется глупый, все подумают что я не знаю эту технологию». Распространенная боль, причем как для джунов, так и для людей с опытом. Для себя я делю все вопросы на две группы: общие и относящиеся к конкретной компании. Общие - легко гуглятся и могут быть решены без привлечения помощи извне. Например, «Как работает постман?» или «Что такое user story?» Я бы не спрашивал такое, а искал ответ самостоятельно.
Специфические вопросы, не стыдно задавать коллегам. «Как устроен бизнес процесс?» «Как работает это сервис?» «Какова моя зона ответственности?» «Есть ли у вас шаблоны документов?» Все то, что нельзя свободно найти в интернете. Коллеги с радостью помогут вам, поделятся информацией или отправят ссылку на конфлюенс.
Касательно обратной связи и понимания «нормальности» работы, отличной практикой является one-to-one с лидом. Когда сотрудник и руководитель созваниваются раз в некоторое время и проговаривают, все ли их устраивает. Если такого процесса в компании нет, точно стоит поговорить с лидом и попросить его назначить такие встречи. Он вряд ли откажет.
В моей практике я именно так и поступил, пришел к руководителю с запросом на one-to-one, ведь только недавно сменил работу и не понимал свой перфоманс. Каждые две недели мы созванивались и делились обратной связью друг с другом. Это очень успокаивает менталку. Вопросы тоже постоянно задаю, ведь многая информация хранится в головах отдельных сотрудников и нигде не отражена.
Не бойтесь общаться, никто не уволит вас за кривой вопрос. Лучше лишний раз спросить/предупредить, чем потратить кучу времени на поиски, промолчать и не успеть в срок.
#база
Частенько ко мне на консультации приходят с запросом: «А как понять, что я хорошо работаю?» Казалось бы, ответ очевиден - если проходишь испытательный срок и тебе не подсвечивают очевидных проблем, значит все прекрасно. Но отсутствие обратной связи, где аналитику прямо говорят - «ты красавчик», сильно бьет по самооценке. Вообще, компании заинтересованы в сохранении сотрудников и должны сами выстраивать процессы таким образом, чтобы новичку было максимально комфортно. Правда, как обычно, в какой момент что-то идёт не так, и ты работаешь, работаешь, работаешь, а понимания того, все ли нормально, так и нет.
Первым советом в такой ситуации будет - «не бояться спрашивать и разговаривать». Большинство рабочих вопросов решаются на месте, и чем думать: «А как бы мне узнать хорошо ли я сделал задачу или нет?», лучше просто спросить. В ИТ, а тем более аналитике, не очень любят молчаливых. Не нужно молчать о проблемах или о возможности сорвать сроки. Если рассказать о своих трудностях, то вас точно поймут и предложат помощь.
Другой страх: «Вдруг я спрошу вопрос, а он окажется глупый, все подумают что я не знаю эту технологию». Распространенная боль, причем как для джунов, так и для людей с опытом. Для себя я делю все вопросы на две группы: общие и относящиеся к конкретной компании. Общие - легко гуглятся и могут быть решены без привлечения помощи извне. Например, «Как работает постман?» или «Что такое user story?» Я бы не спрашивал такое, а искал ответ самостоятельно.
Специфические вопросы, не стыдно задавать коллегам. «Как устроен бизнес процесс?» «Как работает это сервис?» «Какова моя зона ответственности?» «Есть ли у вас шаблоны документов?» Все то, что нельзя свободно найти в интернете. Коллеги с радостью помогут вам, поделятся информацией или отправят ссылку на конфлюенс.
Касательно обратной связи и понимания «нормальности» работы, отличной практикой является one-to-one с лидом. Когда сотрудник и руководитель созваниваются раз в некоторое время и проговаривают, все ли их устраивает. Если такого процесса в компании нет, точно стоит поговорить с лидом и попросить его назначить такие встречи. Он вряд ли откажет.
В моей практике я именно так и поступил, пришел к руководителю с запросом на one-to-one, ведь только недавно сменил работу и не понимал свой перфоманс. Каждые две недели мы созванивались и делились обратной связью друг с другом. Это очень успокаивает менталку. Вопросы тоже постоянно задаю, ведь многая информация хранится в головах отдельных сотрудников и нигде не отражена.
Не бойтесь общаться, никто не уволит вас за кривой вопрос. Лучше лишний раз спросить/предупредить, чем потратить кучу времени на поиски, промолчать и не успеть в срок.
#база
👍18❤10
Как создать хорошую документацию к API?
Казалось бы, очевидный вопрос, особенно когда клепаешь доку каждый день на автомате. Тем удивительнее, скольких аналитиков волнует эта тема. Сегодня разбираем, что должно быть в хорошей документации к API.
Как обычно, все субъективно, но на мой взгляд в API документе содержатся следующие разделы:
1) История изменений
2) Оглавление
3) Системная информация
4) Алгоритм работы
5) Примеры
История изменений. Здесь все просто, ключевая цель раздела - найти того, кто создавал доку или вносил в нее какие-либо изменения. Обычно делаю в виде таблице с колонками: дата изменения, описание изменений, связанная задача, автор изменений. Если в компании используется Jira/Confluense, связка задачи и доки будет отражаться сразу в обоих местах.
Оглавление. Для быстрой навигации по разделам документа. В конфе можно настроить автоматически.
Системная информация. Или «нефункциональные требования». Например, требования к аутентификации, порядок ретраев и таймаутов, тип входного и выходного объекта (если описываете адаптер, на вход может прийти XML, а на выходе JSON), название очереди. В общем указывается вся важная информация, которая не относится к алгоритму работы напрямую.
Алгоритм работы. Самое важное. По шагам расписываем, как работает тот или иной метод. Указываем откуда приходит сообщение (из очереди или из внешней системы или по триггеру и тд), прикладываем пример входящего сообщения. Далее описываем что мы делаем с этим сообщением: раскладываем в базу, преобразуем, формируем новый запрос и тд. Допустим, мы формируем новый запрос, тогда прикладываем его пример в формате curl, указываем метод HTTP и url, а также подробно описываем параметры запроса.
Для описания параметров запроса обычно использую таблицу со следующими колонками: название параметра, описание параметра, пример, тип данных, обязательность, маппинг, дополнительные комментарии.
Затем описываем ответ, алгоритм тот же: прикладываем пример ответа и подробное описание параметров ответа.
Наконец, если требуется обработать ответ, то указываем, как мы его обрабатываем: записываем в поля таблицы или формируем новое сообщение или отправляем в очередь и тд.
Примеры. Их можно указывать отдельно в конце или по ходу выполнения алгоритма, как я написал выше. Примеры очень важны! Они сильно упрощают работу разработчикам и тестировщикам.
Может показаться, что описание слишком подробное и пошаговое, но таким образом нас понимают несколько групп пользователей. Разработчики видят техническую информацию и понимают как им работать, тестировщики могут быстро кидать примеры и проверять работоспособность, бизнес понимает, как работает сервис, другие аналитики смогут без проблем разобраться в текущей документации. И все в плюсе.
В качестве бонуса, для технического описания API я бы не стал придумывать велосипед и просто использовать формат OpenAPI. Нашел ультимативный гайд, где подробно описано как документировать API.
Если наберем 25 реакций, скину пример своей документации из практики)
#база
Казалось бы, очевидный вопрос, особенно когда клепаешь доку каждый день на автомате. Тем удивительнее, скольких аналитиков волнует эта тема. Сегодня разбираем, что должно быть в хорошей документации к API.
Как обычно, все субъективно, но на мой взгляд в API документе содержатся следующие разделы:
1) История изменений
2) Оглавление
3) Системная информация
4) Алгоритм работы
5) Примеры
История изменений. Здесь все просто, ключевая цель раздела - найти того, кто создавал доку или вносил в нее какие-либо изменения. Обычно делаю в виде таблице с колонками: дата изменения, описание изменений, связанная задача, автор изменений. Если в компании используется Jira/Confluense, связка задачи и доки будет отражаться сразу в обоих местах.
Оглавление. Для быстрой навигации по разделам документа. В конфе можно настроить автоматически.
Системная информация. Или «нефункциональные требования». Например, требования к аутентификации, порядок ретраев и таймаутов, тип входного и выходного объекта (если описываете адаптер, на вход может прийти XML, а на выходе JSON), название очереди. В общем указывается вся важная информация, которая не относится к алгоритму работы напрямую.
Алгоритм работы. Самое важное. По шагам расписываем, как работает тот или иной метод. Указываем откуда приходит сообщение (из очереди или из внешней системы или по триггеру и тд), прикладываем пример входящего сообщения. Далее описываем что мы делаем с этим сообщением: раскладываем в базу, преобразуем, формируем новый запрос и тд. Допустим, мы формируем новый запрос, тогда прикладываем его пример в формате curl, указываем метод HTTP и url, а также подробно описываем параметры запроса.
Для описания параметров запроса обычно использую таблицу со следующими колонками: название параметра, описание параметра, пример, тип данных, обязательность, маппинг, дополнительные комментарии.
Затем описываем ответ, алгоритм тот же: прикладываем пример ответа и подробное описание параметров ответа.
Наконец, если требуется обработать ответ, то указываем, как мы его обрабатываем: записываем в поля таблицы или формируем новое сообщение или отправляем в очередь и тд.
Примеры. Их можно указывать отдельно в конце или по ходу выполнения алгоритма, как я написал выше. Примеры очень важны! Они сильно упрощают работу разработчикам и тестировщикам.
Может показаться, что описание слишком подробное и пошаговое, но таким образом нас понимают несколько групп пользователей. Разработчики видят техническую информацию и понимают как им работать, тестировщики могут быстро кидать примеры и проверять работоспособность, бизнес понимает, как работает сервис, другие аналитики смогут без проблем разобраться в текущей документации. И все в плюсе.
В качестве бонуса, для технического описания API я бы не стал придумывать велосипед и просто использовать формат OpenAPI. Нашел ультимативный гайд, где подробно описано как документировать API.
Если наберем 25 реакций, скину пример своей документации из практики)
#база
GitHub
learnapidoc-ru/README.md at master · docops-hq/learnapidoc-ru
Курс по документированию API. Вольный перевод курса https://idratherbewriting.com/learnapidoc/, составленного Томом Джонсоном, техническим писателем Amazon. - docops-hq/learnapidoc-ru
👍30❤6🙏2🌚1
Какой курс выбрать?
Вопрос прилетает мне регулярно. И хотя я всем отвечаю, что не проходил ни одного, а получал профильное образование, новичкам от этого не легче. Сегодня разбираемся, как выбрать лучший курс по системному анализу.
На мой взгляд любой курс нужно проверять по нескольким критериям: наполняемость, наличие ментора, продолжительность и цена.
Наполняемость. Курс должен покрывать все ключевые темы системного анализа. От сбора и работы с требованиями, до баз данных, архитектуры и интеграций. Помимо теории, обязательно должна присутствовать практика, благодаря которой кандидат научится пользоваться основными инструментами.
Наличие ментора. Ментор - тот человек, который направит и поможет разобраться. Тот, к кому можно обратиться в любой момент. Современные курсы предоставляют такие услуги, но чаще всего за одним человеком может быть закреплено более десяти кандидатов. Сами понимаете, в таком случае один ментор не сможет уделить проблеме достаточное время. Лучше уточнять этот момент заранее.
Продолжительность. Я убежден, что оптимальная продолжительность курса по системному анализу не более 3х месяцев. Далее наступает простое выкачивание денег. По опыту, занимаясь раз в неделю с учениками, мы выходим на собеседования как раз через 2-3 месяца.
Цена. Тут все просто, есть бесплатные курсы, есть платные. Платные, как правило, выдают диплом на выходе. Вот только он может не котироваться. Точно знаю, что Яндекс выдает диплом государственного образца, но там и цена соответствующая. С другой стороны, бесплатные, это как правило записи прошедших встреч, и толку от них может быть не так много.
В качестве бонуса примеры хороших курсов:
https://getanalyst.ru/education
https://nextway.pro/
https://practicum.yandex.ru/systems-analyst/?from=catalog
И пример неудачного, здесь покрыты темы только бизнес анализа:
https://1.changellenge.com/business-analyst?utm_source=ip&utm_medium=noukash&utm_campaign=youtube240123#join
Вопрос прилетает мне регулярно. И хотя я всем отвечаю, что не проходил ни одного, а получал профильное образование, новичкам от этого не легче. Сегодня разбираемся, как выбрать лучший курс по системному анализу.
На мой взгляд любой курс нужно проверять по нескольким критериям: наполняемость, наличие ментора, продолжительность и цена.
Наполняемость. Курс должен покрывать все ключевые темы системного анализа. От сбора и работы с требованиями, до баз данных, архитектуры и интеграций. Помимо теории, обязательно должна присутствовать практика, благодаря которой кандидат научится пользоваться основными инструментами.
Наличие ментора. Ментор - тот человек, который направит и поможет разобраться. Тот, к кому можно обратиться в любой момент. Современные курсы предоставляют такие услуги, но чаще всего за одним человеком может быть закреплено более десяти кандидатов. Сами понимаете, в таком случае один ментор не сможет уделить проблеме достаточное время. Лучше уточнять этот момент заранее.
Продолжительность. Я убежден, что оптимальная продолжительность курса по системному анализу не более 3х месяцев. Далее наступает простое выкачивание денег. По опыту, занимаясь раз в неделю с учениками, мы выходим на собеседования как раз через 2-3 месяца.
Цена. Тут все просто, есть бесплатные курсы, есть платные. Платные, как правило, выдают диплом на выходе. Вот только он может не котироваться. Точно знаю, что Яндекс выдает диплом государственного образца, но там и цена соответствующая. С другой стороны, бесплатные, это как правило записи прошедших встреч, и толку от них может быть не так много.
И пример неудачного, здесь покрыты темы только бизнес анализа:
👍8🔥3🤝2❤1
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