Comments 39
Чем REST отличается от SOAP... Почему от SOAP, а не от, скажем, RPC?
А чем Вам SOAP не RPC?
Потому что сами не знают этого паттерна XD
А если рассказать им про варианты использования JSON-RPC, то примут с распростертыми объятиями. А если объяснить интервьюеру про корреляцию между JSON-RPC и GraphQL, то сразу синьером сделают :)
Кажется, стоит начать с того что rest и rpc это паттерн, а soap протокол )
Потому что REST и SOAP очень широко известные баззворды, которые всегда на слуху:)
Хорошая статья.
Если рекрутеры в разговоре спрашивают вас, каков ваш «комфортный уровень зарплаты» - значит они хотят поставить вас заведомо в невыгодную переговорную позицию. Пусть дают свой оффер сперва. Вы показали товар - пусть показывают деньги. Все честно.
Склонен не согласиться и открыт к диалогу.
Для меня (как лица, которого нанимают и которое нанимает) вопрос зарплатных ожиданий важен в первую очередь для того, чтобы быть уверенным, что специалист через n-времени не уйдет потому что "недооценил" себя на рынке.
Если ожидания выше того, что может предложить компания, то уведомил об этом. Если ниже, то за что себя корить, если это правдивый ответ по комфорту?
Очень хорошо, если у вас такая мотивация - вы можете тогда просто попробовать предложить рыночную цену+50% чтобы получить хорошего кандидата (если ему, конечно, не предложат х2 ваши конкуренты, хаха) или сделать свой оффер лучше, если его в первый раз отклонили. Но в 99% случаев этот вопрос задается, чтобы попытаться заплатить кандидату меньше, чем он стоит, воспользовавшись его незнанием рыночных данных, которые при этом знает рекрутер (такой себе insider trading). А следовательно, не стоит упрощать ему задачу и выкладывать все свои карты на стол (у рекрутера и так в рукаве четыре туза)
На такие вопросы и разработчики не только лишь все ответят.
Интересная статья, спасибо! Добавлю свои 5 копеек:
Чем отличается TCP от UDP?
Какие уровни протоколов вы знаете?
Что такое синхронное и асинхронное шифрование?
Что такое трассировка требований?
Как разрешать конфликт требований от двух разных стейкхолдеров?
Какие способы выявления требований вы знаете?
Как будете искать проблему в работе системы, если потребуется?
Что такое бизнес-процесс?
Что будете делать, если в начале работы встретите много незнакомых терминов?
Чем идентификация отличается от авторизации и аутентификации? (про последние два было в списке, добавил про идентификацию)
Что происходит после ввода урл-адреса в адресную строку и нажатия клавиши Enter? (этот вопрос, по сути, прямая отсылка к статье)
Какой главный инструмент в работе аналитика?
Ну и встречались еще общие для собеседований задачки, а-ля "как оптимально разрезать шоколадку n*m" или "какую стратегию выберете, если вы едете навстречу по узкой дороге с другим авто". Ну и часто бывают "игры" на выявление требований к системе в духе вашей кофеварки: составить требования для китайцев на изготовление ручки, задокументировать требования к системе почтовых рассылок и т.п.
Асинхронное шифрование... Кандидат засыпался. Может, асимметричное и симметричное?
Как разрешать конфликт требований от двух разных стейкхолдеров?
А действительно как? Камень, ножницы, бумага или запереть их в кладовке, пока конфликт не разрешиться сам?
Камень, ножницы, бумага или запереть их в кладовке, пока конфликт не разрешиться сам
Ну предложенные методы - это тоже ответ))
Наверняка существуют и другие методы. Еще один пример: если один стейкхолдер приоритетнее другого для нашего проекта, то победа отдается его требованию. Поиск компромисса - тоже вариант. Эскалация на спонсора проекта - еще вариант (кто платит, тот и заказывает музыку). Продолжите список...
Вы и так почти всё назвали :) Кроме самого распространённого и действенного метода - запереть в кладовке собрать вместе на совещании и закрыть дверь изнутри вести это совещание для выработки устраивающего всех решения. Дальше всё зависит от ведущего встречу (скорее всего, серию встреч): насколько он может гасить конфликты, держать разговор в конструктивном русле не отклоняясь от повестки и прочее.
А ответ на вопрос
Какой главный инструмент в работе аналитика?Можно?)
Полагаю "документация" скорее всего не подходит
А я вот как раз ответил, что документация :) А подразумевалась, наверное, голова. Но в моей голове все не удерживается, поэтому мне важно фиксировать где-то в экзокортексе
Получается правильный ответ не сказали?)
А не поделитесь стеком программ, которые используете?
Просто в профессии я буквально 2 месяца только. Вырос из тестировщика в системного аналитика.
Вырос из тестировщика в системного аналитика
да это же просто горизонтальный сдвиг, а не рост))
По инструментам, наверняка, на хабре есть где-нибудь статьи на тему.
Мой ответ скорее такой: Я пользуюсь конфлюенсом. Это основное.
Для схем в разное время использовал visio, yed, gliffy (как плагин к конфлюенсу), lucid.
Доска для CJM, структуризации, связи разного и презентаций: miro
Для личной базы знаний: notion, onenote, obsidian
Макеты: balsamiq, figma
Бывают полезны notepad++, MS Office, atom, питон
Был опыт с Enterprise Architect, но "я пользуюсь конфлюенсом"
33. Составьте схему BPMN для процесса, описывающего работу банкомата (устно)
Устно!?
Добавлю немного.
Какие виды сбора требований вы знаете?
В каком виде вам поступали задачи на аналитику?
Что вы будете делать, если требование поступило максимально сырым?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Как вы определяете состав MVP?
Какие бы вопросы вы задали (вы задавали) другому аналитику на собеседовании?
Какое требование вы бы назвали идеальным и почему?
Плюс, было ещё энное количество вопросов из смежных ролей (так, вопросы из IV SQL и базы данных я отношу к роли DBA, из V Интеграция - к роли архитектора):
из тестирования (отличия blackbox от whitebox)
проектного/продуктового менеджмента (приоритезация фичей)
продуктовой аналитики (метрики востребованности фичи)
дата аналитики (оптимизация взаимодействия исходя из логов)
UX/UI (какие UX принципы знаете)
безопасности (как обеспечить защищённый доступ для сотрудника вне корпоративного контура)
...
да даже разработки!
Не назвал бы их вопросами на стэк или домен, это обычное и естественное желание возложить роль специалиста N на специалиста M, потому что для найма N есть препятствия (задач почти нет, достаточно базовой компетенции, начальство экономит на сотрудниках...)
Какое требование вы бы назвали идеальным и почему?
Очень перекликается с 23. Каким критериям должны соответствовать требования?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Звучит примерно как "Чем роутер отличается от маршрутизатора". Лучше уж спросить определение стейкхолдера (или ЗЛ) или углубиться в тонкости "лицо" vs "сторона"
Очень перекликается с 23
И да, и нет. Идеальное требование с моей точки зрения не существует, т.к. является лишь моделью реальности. Тут как с кодом, если можно обойтись имеющимся - это лучший сценарий. А дальше уже можно составлять достаточно хорошее требование по критериям.
Лучше уж спросить определение стейкхолдера (или ЗЛ) или углубиться в тонкости "лицо" vs "сторона"
Да, пожалуй. Я вёл лишь к тому, что не все заинтересованные лица (например - злоумышленники) должны участвовать в постановке требований, но это не означает, что из их потребностей не могут быть созданы требования. Разговор про тонкости "лицо" vs "сторона" привносит ещё и подтекст корпоративной политики, поэтому будет интересней.
Как человек, который проводит технические собесы, хочу добавить, что если нет реального опыта, то это все равно лучше озвучить, т к то, что кандидат зубрил, сразу выявляется. Не знаешь - скажи. Ну и сразу видно, когда человек гуглит.
К вопросам у меня, честно говоря, тоже есть вопросы. Как будто вы готовитесь к собесу на все роли сразу. Мне кажется, более эффективной будет подготовка по требованиям к конкретной вакансии. Все сразу рассказать по всем блокам, которые тут приведены, и привести на каждый вопрос примеры из своего опыта невозможно, а те, кто это может, обычно не ищут работу аналитиком.
Ещё хочу добавить про вопросы: кандидат тоже вас оценивает, и если вы начнёте задавать нерелевантные опыту кандидата и описанию вакансии вопросы, он может решить, что вы его троллите, сделает по вам выводы о работодателе и пойдёт искать более привлекательное место работы.
Очень хорошая статья. Сам оказывался по разные стороны баррикад, сейчас в роли интервьюера.
С вопросами сам замечаю что трудно понять по хардскиллам подходит или нет человек. Я же уделяю внимание на то, как человек подаёт свой ответ, потому что я давно уже разделил аналитиков на два типа:
Аналитик теоретик, любитель книги Виггерса, чтобы все шло по плану, чтобы была обеспечена полнота требований. При таком аналитике возможно потенциально уменьшить количество итераций в разработке. Заметил проблему следующего рода, при таком аналитике разрабы просто могут быть не готовы и не желать такой детальной аналитики, потому что люди ленятся читать длинные постановки и пропадает у них место для воображения.
Аналитик-практик. Обычно не следует всем правила бабока, Виггерса. Зачастую его главная цель - это обеспечить единое видение в задаче у заинтересованных лиц. Может вообще не использовать диаграммы в постановках (иногда вместо постановок удобнее обговорить все очно).
Так вот, я пытаюсь сейчас обеспечить некий необходимый баланс количества практиков и теоретиков. Практики решают задачи, но плохо документируют, в долгосрочной перспективе могут возникнуть трудности, в виде того, что знания будут только в голове. А теоретики все фиксируют, записывают каждую запись в зуме, ведут протокол встреч, но в краткосрочной перспективе долгое ожидание поставки решения.
Можно добавить третий вид аналитик-гибрид: обеспечивает единое видение в задаче у заинтересованных лиц и документирует тот минимум в документации, который могут осилить прочитать разработчики.
Но такой вид вырастает обычно с опытом, как некая золотая середина, когда побываешь "теоретиком" и "практиком" и наступишь на эти грабли, или слишком много в документации, или слишком мало зафиксировал
не могли бы вы рассказать, как проходит типичный рабочий день или типичная работа над проектом аналитика, для тех кто не представляет, что это за профессия?
Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.
Классическая схема полного цикла действий, когда нужно сделать хорошо и чтобы кнопочка красная выглядит следующим образом:
Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)
Собираем с них требования
Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)
При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий
При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них
Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)
Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать
Учитывая ограничения системы, интеграций, регламентов и прочего - создаём документ для разработки с описанием системы и предполагаемой архитектурой, полученной на предыдущем этапе
Собираем разработчиков, проводим демо требований, оперативно заносим всю критику и исправления в документ, просим их примерно оценить сроки работы
Возвращаемся к заказчиком с оценкой, наблюдаем никогда не надоедающую сцену "Я думал тут работы на час, всего кнопочку добавить", проводим раунд торгов по требованиям и определяем MVP с приоритетами
Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков
Мужественно отвечаем на возникшие вопросы
Как оно выглядит со стороны:
1, 3, 12 - пить кофе и заниматься произвольными делами
2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами
4, 9 - собрать совещание, лишь бы не работать
6, 8, 11 - написать документ по итогам встречи
? - работать
Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)