Привет, Хабр! Меня зовут Лиза, и я — руководитель команды подбора. В течение последних 3 лет я активно занимаюсь подбором IT‑специалистов, а системные аналитики занимают отдельное место в моем сердце. За это время я отсмотрела не одну тысячу резюме и провела несколько сотен собеседований. В данной статье я расскажу, как проходит оценка тех.скиллов на этапе IT‑рекрутера, и на что мы обращаем внимание во время общения. Вместе разберем ход собеседования на примере реальной вакансии системного аналитика. А также я поделюсь небольшими лайфхаками, как сделать взаимодействие аналитика и IT‑рекрутера продуктивным и приятным.

Если вы начинающий специалист, который решил строить карьеру в системном анализе, или уже закаленный проектами аналитик, желающий понять, чем руководствуется рекрутер, когда задает «очередной» вопрос, или же если вы начинающий IT‑рекрутер, эта статья будет для вас полезной.

 Привет, Хабр! Меня зовут Глеб Боос, я работаю руĸоводителем департамента центра ĸомпетенций. Последние шесть лет провожу собеседования и технические ревью QA-инженеров и лидов. 

Прошедшей осенью мне посчастливилось выступить на самой рок-н-ролльной конференции для тестировщиков, SQA Days, с темой про нюансы в технических собеседованиях как в роли собеседующего, так и в роли собеседуемого. 

В данной статье я постараюсь освятить все основные проблемы, которые могут возникать на всех этапах собеседования как с точки зрения кандидата, так и с точки зрения тех.эксперта, который проводит оценку знаний. Я постарался обобщить информацию в статье таким образом, чтобы она была полезна не только специалистам в области QA, но и в других IT-направлениях, а также, возможно, и рекрутерам.

Раньше считалось, что работать на аутсорсе непрестижно, там сложно чему-то научиться, профессионально вырасти и погрузиться в продукт. Сейчас всё изменилось. Рассказываем, в чём плюсы для самих специалистов, как такая работа помогает вырасти профессионально, можно ли попросить зарплату больше, чем в найме и всегда ли эти специалисты «чужие» для команды.

Гибкость в выборе

Если говорить о рабочих задачах, ощутимой разницы между ними на аутсорсе и в штате для ИТ-специалиста нет — ключевое отличие заключается в условиях и возможностях. Так, в инхаус сотрудник обычно прикреплён к конкретному проекту, и если по каким-то причинам его что-то не устраивает, перейти на другой проект не всегда возможно, а если возможно, то с большими сложностями. Аутсорсинг более гибкий: во-первых, проекты там обычно короче, а их ротация у специалиста происходит чаще. Во-вторых, если человеку не нравится продукт, над которым он работает, он не сошёлся с командой или решил попробовать себя в новой области — компании проще перевести его на другой проект, чем терять ценного специалиста.

Такая ротация — большой плюс для развития, она даёт возможность получить опыт в разных сферах. Например, если человек работал на проектах для нескольких банков, увидел разные подходы к организации процессов и выбору стека, он может использовать свои знания, чтобы привнести что-то новое в свой следующий проект. А попробовав себя в разных индустриях: финтехе, ретейле, логистике — и выполняя разные задачи с разными технологиями, он быстрее вырастает профессионально.

Привет, Хабр! Меня зовут Глеб Боос, уже много лет работаю в области QA и прошел путь от начинающего тестировщика до руководителя на разных уровнях. За время работы я попробовал себя в различных ролях, включая тим-лида, тест-менеджера, руководителя проектов, ресурсного менеджера, руководителя отдела тестирования и руководителя центра компетенций. Благодаря этому опыту я имел возможность тесно взаимодействовать со смежными отделами, такими как HR, маркетинг, продажи, закупки и финансы.

В своем стремлении внедрять эффективные процессы и улучшать коммуникацию как внутри команд, так и между проектами/отделами, я всегда активно изучал разнообразные источники информации. Книги PMBOK и P2M, статьи на Habr, видеозаписи конференций на YouTube, практические занятия и тренинги, а также общение с профессионалами помогали мне формировать представление о том, как создать эффективную рабочую среду для проектов и команд. Однако недавно я открыл для себя необычный исходный материал для анализа и обучения — сериал «Тед Лассо» от Джейсона Судейкиса и Билла Лоуренса, создателей известного сериала "Клиника".

$ Сразу стоит отметить, что данная статья представляет собой больше творчесĸий анализ в качестве экспериментального подхода, нежели ревью профессиональной литературы или конференции. 

И снова привет, Хабр! Я Ольга Кузнецова, QA Lead.

В прошлый раз я рассказывала, какие Hard skills нужны для входа в тестирование бэка. 

В сегодняшней статье хочу поделиться своими наработками в части коммуникаций внутри команды и предложить разобрать 5 ситуаций, понимание которых поможет повысить результативность коммуникации и ускорить “склейку” между “новой” и “старой” частями команды.

Статья будет построена в формате: “проблема – решение”.

Привет, Хабр! Меня зовут Глеб Боос и я работаю руĸоводителем центра ĸомпетенций по направлению QA в ĸомпании Innovative People.

В этой статье предлагаю рассмотреть, ĸаĸ ChatGPT версии 3.5 может быть применен в тестировании ПО и ĸаĸие преимущества он открывает. 

Привет, Хабр! Меня зовут Ольга Кузнецова, я Senior QA инженер, более 7-ми лет работаю в ИТ-сфере в различных должностях и сегодня хочу поговорить о минимальных необходимых hard skills для тестирования бэкенда. 

Эта статья будет полезна как начинающим тестировщикам, которые входят в  сферу, так и опытным коллегам, которые только сталкиваются с областью бэк-энд тестирования либо хотят структурировать свои знания. А так же эта информация пригодится для тех, кто готовится к собеседованиям или уже их проводит. Здесь представлен и структурирован мой взгляд на данную тему. Если у вас появятся какие-то замечания, и/или дополнения — буду  рада их обсудить в комментариях. 

Информация изложена “от общего к частному”, и в каждом разделе рассказано про минимально-достаточные знания. В самом начале речь пойдёт про навыки, которые необходимы любому тестировщику, в том числе, и бэкэндеру, так как я считаю это неотъемлемой частью. После перейдём к более узко-направленным вещам.

Гибкие методологии давно заняли свое место в разработке программного обеспечения. Но эйфория свободы и самоорганизации постепенно рассеялась. Выступили подводные камни и неудобные пружины Scrum. Подтвердилось, что Kanban годится только для японского сборочного конвейера. А в манифесте Agile все читали только половину (ту, что слева). Концептуальные противоречия с заказчиком не исчезли. Очевидно, нужна новая методология.

Привет, Хабр! Меня зовут Татьяна Шуравина, я системный аналитик Innovative People, работаю на проекте в банковском секторе. Вместе с командой оптимизируем и автоматизируем операции сотрудников банка для обслуживания юридических лиц. В своей первой статье я рассказывала, как стать системным аналитиком без специального образования. Сегодня хочу поделиться с теми, кто начал свой путь в аналитике, тонкостями магического процесса ведения проектной документации. Не для кого не секрет, что зачастую бывает такое, что система есть, а документации, чтобы понять, как она работает, нет. В статье расскажу, какие есть подходы к ведению документации, зачем это нужно и поделюсь практическим опытом.

В ноябре 2022 года опубликован “The Business Analysis Standard” v.1.0. Меня, как руководителя аналитики заказной разработки компании, этот стандарт касается непосредственно, как и многих читателей Хабра. Но в какой мере? Как он влияет на работу бизнес-аналитика, квалифицированного по профессиональному стандарту РФ? Выдвигает ли новые требования к знаниям, умениям, трудовым функциям, действиям бизнес-аналитика? Меняет ли место или процессы проведения бизнес-анализа? Что дает этот стандарт бизнес-аналитику с практической точки зрения? Постараюсь пролить свет на эти вопросы ниже.

Всем привет!

Это снова я и сегодня у нас снова горячая на холивары тема. Но для начала представлюсь для тех, кто у меня тут в первый раз: меня зовут Денис, я живу в IT около 10 лет и за это время опробовал себя в четырех разных специализациях. На текущий момент я — Product Owner в компании Innovative People, но ранее успел пройти дороги QA (от джуна до лида), системного аналитика (от почти джуна до ведущего) и РМа (где заработал первые значимые седины в бороду).

Честно говоря, я всегда завидовал людям, которые могут долгие годы работать в русле одной специальности, последовательно развивая и углубляя экспертизу, без поползновений в стороны или рывков в разных направлениях. К сожалению (или к счастью), мой психотип этого не выдерживает и порой выдергивает из зоны комфорта ровно тогда, когда я только-только в ней обустроюсь и обрутинюсь.

Я знаю, что таких людей, как я, в мире больше, чем один. Именно для вас, друзья, написан этот лонгрид.

Индустрия IT всегда нравилась и нравится мне тем, что здесь можно относительно безболезненно и успешно мигрировать между позициями, осваивать новые роли и при этом не выпадать наружу. Однако не всем это удается, не всегда это приводит к положительному результату, ну и, вообще-то, не всегда это нужно.

 Но давайте пойдем по порядку и начнем с…

Привет, Хабр, я Татьяна Шуравина, системный аналитик, работаю на проекте в банковском секторе. Три года назад я пришла в системный анализ, можно сказать, с улицы — у меня нет профильного образования, в системном анализе мне пришлось все изучать с нуля. До этого я работала руководителем HR-отдела и занималась в основном бюджетированием, сметами расходов на персонал и развитием корпоративной культуры.  На написание этой статьи меня, подтолкнули размышления о том, что около 70% специалистов приходят в системный анализ из других сфер. В связи с этим, могу сказать, что отсутствие специального образования не является стоп-фактором для того, чтобы начать свой путь и развитие в аналитике. В своей статье, расскажу, как войти в профессию, посоветую то, что мне помогло стать хорошим специалистом.

Недавно мы провели работу над мобильным приложением, которое позволяет регистрировать беговые тренировки и контролировать показатели в ходе тренировки и по окончании. Хочу поделиться с вами алгоритмом, который мы для этого разработали и рассказать, как решили возникшие сложности.
Если кратко, можно улучшить вычисление суммарного подъема и спуска спортсмена в ходе беговой тренировки путем сглаживания профиля маршрута методом взвешенного скользящего среднего. В статье предложен способ взвешивания. Исходными данными послужили обезличенные маршруты тренировок.

Привет! В своей первой статье на Хабре я хотела бы рассказать вам много интересного, полезного и нового. Давайте познакомимся! Меня зовут Катя Прошкина и я методолог Innovative People. Кто такой методолог? Чем он занимается? Как стать востребованным в профессии и не споткнуться о подводные камни? Обо всем этом и не только я расскажу в этой статье.

Всем привет! И сегодня мы поговорим про то, о чем принято спорить до пены у рта или задумчиво молчать с непониманием происходящего. А именно, о разнице между такими существами айтишного бестиария, как системный аналитик (англ. SA или рус. СА) и бизнес-аналитик (англ. BA или рус. БА).

Вступление: кто и про что

Для начала небольшой дисклеймер. В IT я тружусь с 2015 года в найме и на 2-3 года дольше, если считать попытки в стартапы и бизнес, и за это время увидел массу интерпретаций ролей специалистов в разработке. Последние несколько лет я трудился в роли системного аналитика в двух компаниях, а ранее вдоволь понаблюдал за работой бизнес-аналитиков в еще одной, частично подменяя их по ситуации. В текущий момент я перешел к роли Product Owner на своем проекте в Innovative People, однако совсем недавно был ведущим в системной аналитике, так что память свежа.

Эта статья не является истиной в последней инстанции, да и ничто не может быть абсолютной истиной, так как в IT достаточно гибко работает подстройка функций члена команды под конкретные задачи компании и видение команды (и это хорошо!). Так что воспринимайте сей рассказ как обзорную информацию для тех, кто “хочет войти в IT”, либо “хочет войти в аналитику”, либо прямо сейчас столкнулся с задачей сборки команды и пытается разобраться, кого нанимать и для каких целей.

А теперь поехали.