Я проходил технические собеседования на системного аналитика в самых разных компаниях и каждый раз записывал все вопросы. У меня накопилось 120 вопросов. Список вопросов выкладываю в этой статье. Даю гарантию, что, подготовившись по этим вопросам, вы будете успешно проходить технические собеседования в большинстве, если не во всех, it-компаниях. Почему? Потому что большинство вопросов повторяются от собеседования к собеседованию. Очень высока вероятность того, что вопросы, которые вам будут задавать, будут из этого списка.
Про форматы технических собеседований
Традиционно техническое собеседование состоит из двух частей: сначала тебя просят рассказать о своем опыте работы, а потом задают теоретические вопросы.
Встречаются собеседования, которые проходят вообще без теоретических вопросов – спрашивают только про твой опыт – что ты делал на проектах. Это самые простые собеседования.
Другая крайность – «соковыжималка» – часовое или 1,5-часовое собеседование с огромным количеством теоретических вопросов по всем темам. Очень похоже на тестирование. Выжимают все соки. Вопросы из нескольких таких «соковыжималок» тоже попали в мой список.
Что делать, когда вы не знаете ответ на вопрос
Техническое собеседование выглядит как экзамен, но на самом деле, это не экзамен. Если вам задают вопрос, на который вы не знаете ответа, не тушуйтесь, смело говорите – не знаю, не сталкивался с этой темой. Да вы и не обязаны знать всё, о чем вас спрашивают. Задача собеседующего понять, где вы сильны, а где слабы. Это нормально, что вы чего-то не знаете. Ваша спокойная реакция на сложный вопрос – это уже хороший ответ!
Первое правило успешного прохождения технического собеседования - подготовка
Главное – подготовка. Нужно повторить все темы, по которым вас могут спрашивать. Как это сделать? Просто нужно знать, на какие темы чаще всего задают вопросы (см. ниже). И повторить эти темы, читая статьи на Хабре.
Вот эти темы:
Требования (виды требований, работа с требованиями, форматы use case и user story);
Нотации UML и BPMN;
SQL и базы данных;
Интеграции (REST, SOAP, XML, XSD, брокеры сообщений, микросервисы и пр.);
Методологии разработки ПО
После каждого собеседования записывайте вопросы и повторяйте их к следующему собеседованию. Вы увидите, что многие вопросы (и даже задачи) повторяются.
Самый популярный технический вопрос
Абсолютный лидер среди всех технических вопросов: «Что такое REST и чем REST отличается от SOAP?»
Найдите статьи на Хабре на эту тему и будьте готовы к этому вопросу!! Этот вопрос задают почти на каждом собеседовании. А тема интеграций – это тема номер один на собеседованиях.
А вот несколько самых популярных общих вопросов.
«Расскажите про рабочий процесс на последнем вашем проекте»
Один из самых частых вопросов - когда тебя просят рассказать, как на твоей работе был построен рабочий процесс. Вот тут может возникнуть желание приукрасить, особенно если ваш эджайл совсем не эджайл. Этого делать не надо – нужно рассказывать именно так, как все было на самом деле, со всеми недостатками рабочего процесса (а у кого их нет?). Нужна реальная, а не приукрашенная картина.
«Расскажите, что содержится в вашей типовой постановке задач для разработчика»
Тоже один из самых частых вопросов. Лучше всего заранее вспомнить какие-то примеры из своей практики.
Вопросы и задачи на знание SQL
Знания SQL проверяют очень часто. Это могут быть устные вопросы на знания SQL. Или показывают модель данных и просят написать sql-запрос в онлайн-чате или выполнить sql запрос в специальной программе на тестовой базе данных. Для изучения (повторения) SQL можете использовать отличные онлайн-тесты на https://www.sql-ex.ru/. Уровень этих тестов выше, чем задачи на собеседованиях.
Вопросы на реальных технических собеседованиях на должность системного аналитика
(частые вопросы выделены жирным шрифтом)
I Общие вопросы
1. Почему вы меняете работу?
2. Расскажите о себе и своем опыте.
3. Расскажите, что вы делали как аналитик.
4. Какую работу вы ищете?
5. Что вы хотите получить от новой работы?
6. Что вам нравится делать как аналитику и что не нравится?
7. Какими достижениями в своей работе вы гордитесь?
8. Как вы относитесь к переработкам?
9. Опишите своего идеального руководителя.
10. Опишите идеальную для вас команду.
11. Что самое сложное было для вас в работе?
12. Расскажите о своей самой сложной/важной работе за последние полгода.
13. Кем вы себя видите через 2 года? Через 5 лет?
14. Были ли у вас провалы?
15. Были ли у вас конфликты с коллегами и как вы их решали?
16. Как решались технические разногласия в команде?
17. Какую последнюю книгу вы прочли?
18. Чем вы любите заниматься?
19. Приходилось ли вам работать со сложным заказчиком и как вы улаживали разногласия?
20. У вас есть портфолио аналитика? Пришлите что-нибудь из вашего портфолио.
II Требования
21. Какие группы требований вы знаете?
22. Что входит в нефункциональные требования?
23. Каким критериям должны соответствовать требования?
24. Вам аналитик принес список требований. Как вы их оцените?
25. Приходилось ли вам писать Use cases? Как пишутся Use cases?
26. Приходилось ли вам писать User story?
27. Вы продаете кофейные аппараты. Я заказчик. Какие вопросы вы зададите потенциальному заказчику, который хочет купить кофейный аппарат в офис? (заказчик при этом на все вопросы отвечает «не знаю»)
28. С какими группами заинтересованных лиц вы общались?
III Нотации UML и BPMN
29. Какими нотациями вы владеете?
30. Какими UML диаграммами вы пользуетесь?
31. Нарисуйте диаграмму последовательности для процесса, когда пользователь через веб-форму отправляет запросы в rest-сервис для получения данных.
32. Что такое диаграмма последовательности? (Что описывает диаграмма последовательности?)
33. Составьте схему BPMN для процесса, описывающего работу банкомата (устно)
34. Какие бывают Gateway в BPMN?
35. Какие элементы BPMN вы знаете?
IV SQL и базы данных
36. Приходилось ли вам писать sql-запросы? Для чего?
37. Зачем нужны индексы в таблицах БД?
38. Знакомы ли вы с нормализацией баз данных?
39. Задача на нормализацию таблиц базы данных. Дают две таблицы с некоторыми полями. Что в них не так и почему? Как исправить?
40. Какие виды JOIN запросов вы знаете?
41. Задача sql. Дают таблицы. Напишите SELECT с такими-то условиями запроса (задача на JOIN).
42. Задача sql. Дают таблицы. Напишите SELECT с такими-то условиями запроса (задача на GROUP BY).
43. Даются следующие три операции SQL. Какой будет результат?
TRUNCATE TABLE;
ROLLBACK;
SELECT * FROM TABLE;
44. Чем TRANCATE отличается от DELETE?
45. Дается SQL запрос. Назовите все ошибки в синтаксисе, которые вы видите.
46. Назовите все способы в SQL выбрать данные из первой таблицы, которых нет во второй таблице (NOT IN, NOT EXISTS и др).
47. Что такое транзакция?
48. Какими свойствами должна обладать транзакция? (ACID)
49. Чем отличается UNION от UNION ALL?
50. Какие типы JOIN вы знаете? Чем LEFT JOIN отличается от FULL JOIN ?
51. Можете назвать три первые формы нормализации?
52. Что такое первичный ключ? Каким свойством обладает первичный ключ? Что такое внешний ключ?
53. Что такое поисковые пути в базах данных?
54. Какие бывают представления в БД?
55. Для чего используется HAVING в SQL?
V Интеграция
56. Что такое XSD?
57. Что содержится в XML?
58. Чем sequence отличается от choice в XSD?
59. Приходилось ли вам писать XSD?
60. Что такое пространство имен в XML?
61. Какими программами вы работали с XML?
62. Что такое WSDL?
63. Чем SOAP отличается от REST?
64. Из чего состоит сообщение в SOAP?
65. Что содержит HEADER в ответе REST?
66. Чем отличается ошибка 200 от 201?
67. Какие методы REST вы знаете?
68. Чем POST отличается от GET?
69. Чем PUT отличается от PATCH?
70. Приходилось ли вам писать JSON? С помощью чего вы писали JSON?
71. Напишите пример rest-API для книжной библиотеки (напишите методы, эндпоинты и пример JSON).
72. Что содержит URL в REST запросе?
73. Как проверить, что сообщение брокера получено в полном объеме?
74. Знаете ли вы CAP-теорему?
75. Что такое stateless и stateful, если говорить про сервисы? Rest – это какие сервисы? Что значит stateless сервисы?
76. Что такое идемпотентность? Почем это важно?
77. DELETE – идемпотентный метод?
78. Приходилось ли вам проектировать взаимодействие информационных систем?
79. Что такое корпоративная шина? Приходилось ли работать с корпоративной шиной?
80. Чем корпоративная шина отличается от ETL – инструмента?
81. Чем брокер сообщений отличается от корпоративной шины?
82. К корпоративной шине подключены веб-сервисы. В одном веб-сервисе появились два новых обязательных поля. Что изменится в интеграции?
83. Есть некий UI, нужно написать к нему веб-сервис. Опишите вашу постановку – что в ней будет.
84. Что такое синхронные и асинхронные вызовы?
85. Приходилось ли вам работать с брокерами сообщений?
86. Для чего вы использовали брокер сообщений?
87. Как брокер сообщений гарантирует доставку сообщений?
88. Чем Kafka отличается от RabbitMQ?
89. Есть две системы. Назовите все способы интеграции этих систем.
90. Какие виды/способы интеграции вы знаете?
91. Клиент читает в Kafka два последних сообщения. Как тому же клиенту заново
прочитать эти два последние сообщения?
92. Приходилось ли вам проектировать API в нотации OpenAPI/Swagger?
93. Опишите все способы снизить нагрузку на вебсервис.
94. Есть четыре системы, участвующие в последовательном исполнении заказа клиента на выдачу карты: форма заявки на выдачу карты, скоринг, печать карты, логистика. Опишите, как вы их интегрируете между собой.
95. Знакомы ли вы с микросервисами?
96. Что такое Хореография и Оркестрация?
97. Какие достоинства и недостатки микросервисов вы знаете?
98. Расскажите про токен-авторизацию в микросервисах.
VI Методологии разработки ПО
99. Чем Kanban отличается от Scrum?
100. В каких методологиях вам приходилось работать?
101. Какие методологии разработки программного обеспечения вы знаете?
102. Опишите процесс работы, который был принят на вашем проекте.
VII Прочие вопросы
103. Чем авторизация отличается от аутентификации?
104. Знакомы ли вы с электронными подписями? Как они работают?
105. Что такое sftp?
106. Как работает https?
107. Есть карандаши, фломастеры и ручки. Опишите для них примеры классов (наименования, атрибуты, методы).
108. Приходилось ли вам работать с AsciiDoc или MarkDown разметкой?
109. Опишите, что обычно содержится в вашей постановке для разработчиков?
110. Чем бизнес-аналитик отличается от системного аналитика?
111. Чем ГОСТ 19 отличается от ГОСТ 34?
112. Приходилось ли вам писать спецификации?
113. Какие документы по ГОСТУ вы писали?
114. Что такое анализ, синтез?
115. Что такое уровень абстракции?
116. Приходилось ли вам самому тестировать ПО?
117. Что можете рассказать про хеширование?
118. Какие способы разграничения доступа вы знаете?
119. Задача: опишите типовые составные части АИС, не входящие в основной функционал (какие подсистемы АИС есть в большинстве АИС).
120. С какими языками программирования знакомы? Сможете прочитать и разобрать код, написанный на Java?
И несколько заметок о текущем рынке труда
Теперь поговорим о спросе и предложении на рынке аналитиков. После того как вы успешно пройдете техническое собеседование и продемонстрируете высокий уровень знаний, ваша цена как специалиста вырастет в глазах нанимателя. Можно подумать и о повышении зарплаты, не правда ли?
Спрос на аналитиков сейчас (в 2021) очень высок. Только с одного hh.ru на резюме приходит до 20-30 приглашений на собеседования в день (Senior analyst, з/п свыше 200 т.р., Москва). Рекрутеры буквально упрашивают прийти к ним на собеседование. Все это говорит о том, что это уже не рынок покупателя, а рынок продавца. Дефицит кадров. Соответственно растут и офферы. (Диапазон широк – на должность ведущего аналитика предлагают з/п от 200 до 300 net, в зависимости от компании).
Если рекрутеры в разговоре спрашивают вас, каков ваш «комфортный уровень зарплаты» – это намек на то, что вы указали в резюме зарплату ниже рынка (или компания готова предложить вам заметно выше). Можете смело поднимать ценник.
Рекрутеры не стесняются спрашивать, какие офферы у вас уже на руках, чтобы предложить больше. Некоторые компании предлагают бонусы за выход (сразу или по окончании испытательного срока).
Если вам показалось, что интересный вам оффер недостаточно высок – не стесняйтесь просить больше, компании охотно идут навстречу опытным специалистам. Аналитики нужны всем.
Дорогие коллеги, я поделился с вами этой базой вопросов потому что считаю, что она может быть полезна многим (как тем, кто проходит, так и тем, кто проводит собеседования). Взамен небольшая просьба. Добавляйте, пожалуйста, вопросы и задачи с собеседований в комментарии. Пусть эта статья постоянно обогащается новыми интересными вопросами и темами. Это будет стимулировать аналитиков больше читать, изучать, развиваться и находить лучшую в мире работу.
Комментарии (39)
Stas911
23.11.2021 20:38+2Хорошая статья.
Если рекрутеры в разговоре спрашивают вас, каков ваш «комфортный уровень зарплаты» - значит они хотят поставить вас заведомо в невыгодную переговорную позицию. Пусть дают свой оффер сперва. Вы показали товар - пусть показывают деньги. Все честно.
MikhailKryukov
24.11.2021 22:09Склонен не согласиться и открыт к диалогу.
Для меня (как лица, которого нанимают и которое нанимает) вопрос зарплатных ожиданий важен в первую очередь для того, чтобы быть уверенным, что специалист через n-времени не уйдет потому что "недооценил" себя на рынке.
Если ожидания выше того, что может предложить компания, то уведомил об этом. Если ниже, то за что себя корить, если это правдивый ответ по комфорту?
ivanych
25.11.2021 01:54Да ну, ерунда. Если вас волнует, что нанимаемый уйдёт - предлагайте сколько можете и всё. Если ему мало - вы больше всё-равно не можете, так что нет смысла спрашивать.
А справают на самом деле, чтобы не предлагать больше, чем он хочет. Всегда потом есть возможность поднять, если что. Но если сразу не просит много - много и не предложат.
Stas911
25.11.2021 04:43Очень хорошо, если у вас такая мотивация - вы можете тогда просто попробовать предложить рыночную цену+50% чтобы получить хорошего кандидата (если ему, конечно, не предложат х2 ваши конкуренты, хаха) или сделать свой оффер лучше, если его в первый раз отклонили. Но в 99% случаев этот вопрос задается, чтобы попытаться заплатить кандидату меньше, чем он стоит, воспользовавшись его незнанием рыночных данных, которые при этом знает рекрутер (такой себе insider trading). А следовательно, не стоит упрощать ему задачу и выкладывать все свои карты на стол (у рекрутера и так в рукаве четыре туза)
axtrace
23.11.2021 22:02Интересная статья, спасибо! Добавлю свои 5 копеек:
Чем отличается TCP от UDP?
Какие уровни протоколов вы знаете?
Что такое синхронное и асинхронное шифрование?
Что такое трассировка требований?
Как разрешать конфликт требований от двух разных стейкхолдеров?
Какие способы выявления требований вы знаете?
Как будете искать проблему в работе системы, если потребуется?
Что такое бизнес-процесс?
Что будете делать, если в начале работы встретите много незнакомых терминов?
Чем идентификация отличается от авторизации и аутентификации? (про последние два было в списке, добавил про идентификацию)
Что происходит после ввода урл-адреса в адресную строку и нажатия клавиши Enter? (этот вопрос, по сути, прямая отсылка к статье)
Какой главный инструмент в работе аналитика?
Ну и встречались еще общие для собеседований задачки, а-ля "как оптимально разрезать шоколадку n*m" или "какую стратегию выберете, если вы едете навстречу по узкой дороге с другим авто". Ну и часто бывают "игры" на выявление требований к системе в духе вашей кофеварки: составить требования для китайцев на изготовление ручки, задокументировать требования к системе почтовых рассылок и т.п.
dmitry_rozhkov
24.11.2021 11:28Как разрешать конфликт требований от двух разных стейкхолдеров?
А действительно как? Камень, ножницы, бумага или запереть их в кладовке, пока конфликт не разрешиться сам?
axtrace
24.11.2021 12:18+1Камень, ножницы, бумага или запереть их в кладовке, пока конфликт не разрешиться сам
Ну предложенные методы - это тоже ответ))
Наверняка существуют и другие методы. Еще один пример: если один стейкхолдер приоритетнее другого для нашего проекта, то победа отдается его требованию. Поиск компромисса - тоже вариант. Эскалация на спонсора проекта - еще вариант (кто платит, тот и заказывает музыку). Продолжите список...
YgReEk
24.11.2021 13:30+3Вы и так почти всё назвали :) Кроме самого распространённого
и действенногометода -запереть в кладовкесобрать вместе на совещании изакрыть дверь изнутривести это совещание для выработки устраивающего всех решения. Дальше всё зависит от ведущего встречу (скорее всего, серию встреч): насколько он может гасить конфликты, держать разговор в конструктивном русле не отклоняясь от повестки и прочее.
Angi1540
24.11.2021 22:09А ответ на вопрос
Какой главный инструмент в работе аналитика?Можно?)
Полагаю "документация" скорее всего не подходит
axtrace
24.11.2021 22:26+1А я вот как раз ответил, что документация :) А подразумевалась, наверное, голова. Но в моей голове все не удерживается, поэтому мне важно фиксировать где-то в экзокортексе
Angi1540
24.11.2021 22:45Получается правильный ответ не сказали?)
А не поделитесь стеком программ, которые используете?
Просто в профессии я буквально 2 месяца только. Вырос из тестировщика в системного аналитика.
axtrace
25.11.2021 01:02+1Вырос из тестировщика в системного аналитика
да это же просто горизонтальный сдвиг, а не рост))
По инструментам, наверняка, на хабре есть где-нибудь статьи на тему.
Мой ответ скорее такой: Я пользуюсь конфлюенсом. Это основное.
Для схем в разное время использовал visio, yed, gliffy (как плагин к конфлюенсу), lucid.
Доска для CJM, структуризации, связи разного и презентаций: miro
Для личной базы знаний: notion, onenote, obsidian
Макеты: balsamiq, figma
Бывают полезны notepad++, MS Office, atom, питон
Был опыт с Enterprise Architect, но "я пользуюсь конфлюенсом"
ivvi
26.11.2021 20:34Ну вообщет неправильно ставить EA и Confluence в один ряд.
Принципиально разные инструменты для разных задач.
axtrace
23.11.2021 22:05+133. Составьте схему BPMN для процесса, описывающего работу банкомата (устно)
Устно!?
K_Chicago
24.11.2021 03:08+2хочу добавить прикольный вопрос по SQL который мне задал один индус видимо чтобы показать свою крутость.
Итак, выполняются следующие операции (речь шла об Oracle):
DELETE FROM <legit table name>; - таблица существует и она непустая
TRUNCATE TABLE blahblahblah; - такой таблицы не существует, вы получаете ошибку ORA-00942: table or view does not exist
ROLLBACK;
SELECT * FROM <legit table name>;
Что получится?
Несколько неожидано, последний SELECT вернёт пустой результат. Я не знал, просто с таким в своей длительной практике никогда не сталкивался.
TRUNCATE выполняет COMMIT дважды, один раз перед выполнением самой команды, второй раз после выполнения. В данном случае COMMIT выполнится один раз, но сделает своё чёрное дело.
PolyAkaMorph
24.11.2021 12:04Здесь нет никакой магии, TRUNCATE - DDL операция, а Oracle перед и после каждой DDL операции делает неявный commit.
YgReEk
24.11.2021 12:09+2Добавлю немного.
Какие виды сбора требований вы знаете?
В каком виде вам поступали задачи на аналитику?
Что вы будете делать, если требование поступило максимально сырым?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Как вы определяете состав MVP?
Какие бы вопросы вы задали (вы задавали) другому аналитику на собеседовании?
Какое требование вы бы назвали идеальным и почему?
Плюс, было ещё энное количество вопросов из смежных ролей (так, вопросы из IV SQL и базы данных я отношу к роли DBA, из V Интеграция - к роли архитектора):
из тестирования (отличия blackbox от whitebox)
проектного/продуктового менеджмента (приоритезация фичей)
продуктовой аналитики (метрики востребованности фичи)
дата аналитики (оптимизация взаимодействия исходя из логов)
UX/UI (какие UX принципы знаете)
безопасности (как обеспечить защищённый доступ для сотрудника вне корпоративного контура)
...
да даже разработки!
Не назвал бы их вопросами на стэк или домен, это обычное и естественное желание возложить роль специалиста N на специалиста M, потому что для найма N есть препятствия (задач почти нет, достаточно базовой компетенции, начальство экономит на сотрудниках...)
axtrace
24.11.2021 12:22+1Какое требование вы бы назвали идеальным и почему?
Очень перекликается с 23. Каким критериям должны соответствовать требования?
Чем стейкхолдеры отличаются от заинтересованных лиц (спорный вопрос про долю участия в проекте)?
Звучит примерно как "Чем роутер отличается от маршрутизатора". Лучше уж спросить определение стейкхолдера (или ЗЛ) или углубиться в тонкости "лицо" vs "сторона"
YgReEk
24.11.2021 13:25Очень перекликается с 23
И да, и нет. Идеальное требование с моей точки зрения не существует, т.к. является лишь моделью реальности. Тут как с кодом, если можно обойтись имеющимся - это лучший сценарий. А дальше уже можно составлять достаточно хорошее требование по критериям.
Лучше уж спросить определение стейкхолдера (или ЗЛ) или углубиться в тонкости "лицо" vs "сторона"
Да, пожалуй. Я вёл лишь к тому, что не все заинтересованные лица (например - злоумышленники) должны участвовать в постановке требований, но это не означает, что из их потребностей не могут быть созданы требования. Разговор про тонкости "лицо" vs "сторона" привносит ещё и подтекст корпоративной политики, поэтому будет интересней.
axtrace
24.11.2021 22:27Я вёл лишь к тому, что не все заинтересованные лица (например - злоумышленники) должны участвовать в постановке требований, но это не означает, что из их потребностей не могут быть созданы требования
Теперь понял. Отличное пояснение! Мисюзкейсы наше все!
froav
24.11.2021 12:23Как человек, который проводит технические собесы, хочу добавить, что если нет реального опыта, то это все равно лучше озвучить, т к то, что кандидат зубрил, сразу выявляется. Не знаешь - скажи. Ну и сразу видно, когда человек гуглит.
К вопросам у меня, честно говоря, тоже есть вопросы. Как будто вы готовитесь к собесу на все роли сразу. Мне кажется, более эффективной будет подготовка по требованиям к конкретной вакансии. Все сразу рассказать по всем блокам, которые тут приведены, и привести на каждый вопрос примеры из своего опыта невозможно, а те, кто это может, обычно не ищут работу аналитиком.
Ещё хочу добавить про вопросы: кандидат тоже вас оценивает, и если вы начнёте задавать нерелевантные опыту кандидата и описанию вакансии вопросы, он может решить, что вы его троллите, сделает по вам выводы о работодателе и пойдёт искать более привлекательное место работы.
rrttgg
24.11.2021 22:11+3Очень хорошая статья. Сам оказывался по разные стороны баррикад, сейчас в роли интервьюера.
С вопросами сам замечаю что трудно понять по хардскиллам подходит или нет человек. Я же уделяю внимание на то, как человек подаёт свой ответ, потому что я давно уже разделил аналитиков на два типа:
Аналитик теоретик, любитель книги Виггерса, чтобы все шло по плану, чтобы была обеспечена полнота требований. При таком аналитике возможно потенциально уменьшить количество итераций в разработке. Заметил проблему следующего рода, при таком аналитике разрабы просто могут быть не готовы и не желать такой детальной аналитики, потому что люди ленятся читать длинные постановки и пропадает у них место для воображения.
Аналитик-практик. Обычно не следует всем правила бабока, Виггерса. Зачастую его главная цель - это обеспечить единое видение в задаче у заинтересованных лиц. Может вообще не использовать диаграммы в постановках (иногда вместо постановок удобнее обговорить все очно).
Так вот, я пытаюсь сейчас обеспечить некий необходимый баланс количества практиков и теоретиков. Практики решают задачи, но плохо документируют, в долгосрочной перспективе могут возникнуть трудности, в виде того, что знания будут только в голове. А теоретики все фиксируют, записывают каждую запись в зуме, ведут протокол встреч, но в краткосрочной перспективе долгое ожидание поставки решения.
anna_ovzyak
25.11.2021 11:36+1Можно добавить третий вид аналитик-гибрид: обеспечивает единое видение в задаче у заинтересованных лиц и документирует тот минимум в документации, который могут осилить прочитать разработчики.
Но такой вид вырастает обычно с опытом, как некая золотая середина, когда побываешь "теоретиком" и "практиком" и наступишь на эти грабли, или слишком много в документации, или слишком мало зафиксировал
katletmedown
26.11.2021 10:22не могли бы вы рассказать, как проходит типичный рабочий день или типичная работа над проектом аналитика, для тех кто не представляет, что это за профессия?
K_Chicago
26.11.2021 11:23+1Я представляю примерно так:
утренний стэнд-ап (15 мин)
попить кофе (30 мин)
прочитать все емейлы со вчерашнего дня, ответить (15 минут)
поприсутствовать на очередных реглуярных идиотических митингах - backlog grooming, sprint planning etc etc (1 час)
почитать ассайненные на тебя ITRs/Tickets (30 мин)
Взять тот тикет который не кажется очевидно бредовым, выяснить какие бизнес-юзеры и какие девелоперы вовлечены(30 мин)
Разослать инвайты на митинг всем вовлеченным бизнес-юзерам и девелоперам, согласовать время митинга (не менее часа) - 30 мин.
Перерыв на ланч (1 час)
послеобеденный браузинг интернета (1 час)
пойти на назначенный митинг с бизнес-юзерами и девелоперами (с прошлого раза), 1 час
составить документ по итогам прошедшего митинга, внести его в Jira (1 час)
попить кофе с плюшками (30 мин)
ответить на детальные технические вопросы девелоперов после недавнего митинга, суть ответа - назначить новый митинг с девелоперами и бизнес-юзерами для обсуждения их вопросов, длительность - не менее часа (30 мин)
найти девелопера-доброхота и попросить его объяснить, об чём вообще речь в текущем ITR и что вообще они собираются в связи с этим делать(30 мин)
по крайней мере наш свеженанятый бизнес-аналитик из Непала(!!!) первые 2-3 года работал именно так. Ну, плюс дополнительные нагрузки ("Скажем так...и ещё я готовлю" (с)Стивен Сигал "В осаде") - он готовил для всех желающих документы "Business requirements" по шаблону, абсолютно пустопорожние но этим сильно облегчал жизнь девелоперов, за что его все любили)
А сейчас он вырос, уже вовсю самостоятельно проводит стенд-апы и даже пару раз координировал ежемесячный деплоймент.
YgReEk
27.11.2021 12:06+1Вообще, ответ 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 - написать документ по итогам встречи
? - работать
Ivan_Pod
Чем REST отличается от SOAP... Почему от SOAP, а не от, скажем, RPC?
Danik-ik
А чем Вам SOAP не RPC?
XXL13
Потому что сами не знают этого паттерна XD
А если рассказать им про варианты использования JSON-RPC, то примут с распростертыми объятиями. А если объяснить интервьюеру про корреляцию между JSON-RPC и GraphQL, то сразу синьером сделают :)
vialz
Кажется, стоит начать с того что rest и rpc это паттерн, а soap протокол )
davvol
Потому что REST и SOAP очень широко известные баззворды, которые всегда на слуху:)