Comments 376
Навык формулировать четкие и ёмкие определения
Хорошего вы ждёте от Junior. Этим и далеко не каждый мидл похвастать может. Попробуйте, к примеру, сформулировать что такое "Книга" и вы неожиданно столкнётесь с кучей проблем. Считаю навык сформулировать ёмкое и чёткое описание вообще отдельной наукой.
ИМХО, специалисты уровня Junior - это люди, которые умеют делать что-то. Они знают, что если ввести команду Х, то будет Y. О том "как" это происходит, а уж тем более о понимании "почему это происходит именно так, а не иначе" речи не идёт. Не говоря уже об отличии подхода Х от подхода Y. Если человек уровня Junior отвечает правильно на эти вопросы, то он либо имеет хорошую подготовку к собесам или вовсе не Junior. Тут уж senior или, по крайней мере, крепким middle попахивает.
Ну и это, конечно, всё по современным меркам. Раньше да, нужно было всё знать.
А ещё чуть раньше без умения охотится на мамонта было не выжить. Во времена были...
От Junior я жду только "соображалку" и жажду знаний, больше ничего :) Остальное дело наживное.
Но назвать Junior'ом кандидата, который имеет 2-3 года работы по профессии, опыт самостоятельного ведения проекта, и зарплатные ожидания в 200К, у меня язык не поворачивается. При таких вводных я ожидаю что это будет "полноценная боевая единица" - то есть Middle или почти Middle. Возможно здесь вопрос в границе между этими уровнями, это крайне дискуссионный вопрос.
Составлять четкие и ёмкие определения - сложно, с этим я полностью согласен. Но попытаться сформулировать какой-то вариант можно. По крайне мере выделить отличительные признаки.
P.S. Книга - это упорядоченный и сброшюрованный набор листов бумаги, содержащих тематически связанный текст и/или иллюстрации, под общей обложкой. Это если говорить про "книгу" как предмет.
Ну не знаю, вообще-то все кроме зарплатных ожиданий тут как раз от джуна. Я не знаю, где вы видели миддлов с опытом 2-3 года, мне такие не попадались вроде.
>опыт самостоятельного ведения проекта
А как вы его измеряете? Мне попадался в жизни совершенно безграмотный аналитик, который пытался меня «строить», в том смысле что «я тут решаю, какие фичи нужны, а какие нет». Я на тот момент был на этом проекте 3.5 года, и сделал его практически с нуля (на пару с еще одним разработчиком и другим аналитиком), и знал всю бизнес часть от и до. При этом этот человек наверняка впишет себе в резюме опыт ведения того проекта. А вели его другие люди, которых вы просто не видите.
Вот вы этот опыт оцениваете — и видите, что его нет. Значит для вас это джун, что бы он не думал про себя сам?
Ну не знаю, вообще-то все кроме зарплатных ожиданий тут как раз от джуна. Я не знаю, где вы видели миддлов с опытом 2-3 года, мне такие не попадались вроде.
Вероятно у нас просто разные границы между Junior и Middle - у вас стандарты выше. У меня много примеров, когда сотрудники в 2-3 годами опыта были Middle (по моей шкале). Граница между Junior и Middle - тема для отдельной холиварной статьи :)
опыт самостоятельного ведения проекта - А как вы его измеряете?
Здесь я просто имею в виду ситуацию, что кандидат ранее работал в команде, где был единственным аналитиком. То есть он сам ходил к заказчику собирать требования, сам составлял спецификацию, сам сдавал работу. В противовес ситуации, когда в команде было несколько аналитиков, и всегда был "старший товарищ" который нарезал задачи и контролировал качество.
Понятно, что кандидат мог приврать и по факту роль "старшего товарища" мог выполнять менеджер или например старший разработчик, но это уже на совести кандидата.
Ну да, я согласен, тут тонкая грань, просто в моей практике после 2-3 лет самостоятельное решение задач (то есть миддл в какой-то степени) далеко не всегда достигается. Наверное такие бывают, но я не видел.
>но это уже на совести кандидата.
Ну я как раз про это. Ему даже врать не особо надо, ведь старшего аналитика же не было…
Здесь возникает любопытный нюанс: а ожидается ли встречный вопрос, говорим ли мы про "книгу" как материальный предмет или как концепцию ("Я работаю над новой книгой" — вряд ли я занимаюсь брошюровкой)? Ну это отчасти холиварный момент, где та разумная грань, когда пора перестать уточнять поставленную задачу и начать предлагать решение.
Если будет вопрос - это в плюс
Если будет озвучено допущение - тоже в плюс
Если без вопросов будет выбран самый логичный вариант - тоже нормально
Ещё не забыть уточнить, какая это книга. Электронная? А, может быть — на свитке? Или вообще — стопка бересты😁. А "книга" на глиняных дощечках — и вовсе не подпадает ни под какое описание....
под это определение и тетрадь подойдет (ну, с незначительной доработкой)
Понятно что определение не идеально. Например паспорт или военный билет тоже под него подойдут. Или отрывной календарь. Его можно долго уточнять и расширять, чтобы отсечь схожие предметы, которые при этом не являются книгами. В результате получим максимально точное определение, длиной страниц на 10, которым совершенно невозможно пользоваться.
Это еще один аспект вопроса "дай определение" - сможет ли кандидат выделить только ключевые характеристики и не закопаться в незначимые мелочи.
По моему опыту, для аналитика практичным способом дать определение будет вариант из классической логики:
1. указать на принадлежность к родовому понятию (или к заданному ряду),
2. указать на ключевые отличия определяемого предмета.
При этом явно или неявно задаётся контекст, т.е. та или иная сфера деятельности, её характерные кейсы, про это всё можно поговорить с кандидатом. Та же книга может быть по-разному определена в зависимости от того, пишу ли я её, издаю, печатаю, транспортирую, продаю или читаю. Хороший аналитик задаст контекст явно, нулевым пунктом.
Неблагоприятные знаки:
1. когда кандидат в аналитики приводит непрактичное определение, с которым ничего нельзя делать.
2. когда контекст не задан, по определению его восстановить не удаётся, или когда происходит путаница со смешением контекстов.
2. когда кандидат строит определение от внутреннего устройства предмета. Все-таки у нас аналитики работают с требованиями, т.е. с контекстом внешнего употребления предмета, а не его внутреннего устройства. В понимании устройства нет ничего плохого, но если ответ начинается с этого, то стоит проверить - может ли кандидат эффективно мыслить в парадигме требований?
В типографском деле книги как раз состоят из нескольких (а то и одной) тетрадей, собранных из большого листа, сложенного в Х раз (например 60х90 1/8 - книга напечатана на листах 60 на 90 см, потом они сложены три раза (2^3 = 8)), немного обрезанного и склеенного/переплетенного
Думается мне это все же книга. То есть текст/иллюстрации не важны.
Это не книга, т.к. отсутствует основной ее признак - содержание в виде текста или графики, но присутствует вторичный - обложка и страницы.
Это иллюстрация книги, которая содержит определенные допущения для упрощения считывания (чтобы в мелком масштабе на страницах не оказалась каша из сплошного черного пятна), чтобы ее можно было визуально вписать куда-то, или для чего-то еще. А может вообще без всякого смысла, тупо ради "красоты")
Хорошо, ну а как бы вы назвали одним словом книгу, до того как в ней что-то написали? Особенно, если это рукописная книга - то есть состояние когда в ней ничего не написано вполне обыденно.
Блокнот.
Рукописные книги - большая редкость (в последние 200-300 лет), на фоне типографских их число - доли процента, поэтому их можно в целом игнорировать (пресловутые "незначимые мелочи"). Типографских же книг, похожих на иллюстрацию выше, не бывает ни на одной стадии технологического процесса - текст сначала печатается на бумаге, затем бумага брошюруется в книгу, а не наоборот. Если же типография выпускает такое изделие, как на картинке, то оно маркетируется как блокнот.
Draft (Черновик)
Согласно толковому словарю Ожегова, как минимум одно определение книги допускает пустые страницы.
2. - сшитые в один переплет чистые или разграфленные большие листы бумаги для записей
Мне кажется, тут имеет место смешение смыслов. Книга как произведение литературы не может быть пустой. Книга как предмет (а именно как предмет и было дано определение) может быть пустой.
Я думаю, что и книга как примет литературы может быть пустой - как литературный эксперимент a-la Кейджевское 4'33''
Она не мешает думать свои мысли, не отвлекает, но одновременно предает нужный (в зависимости от ситуации — задумчивый, или увлеченный, или расслабленный, или воодушевленный) вид, не напрягает глаза, экономит материалы и имеет еще много положительных качеств!
Никто не заявлял, что текст/иллюстрации должны быть на каждой странице. В Книги (особенно по психологии или иностранным языкам) часто вставляют пустые места для заметок читающего. Возможно на иллюстрации книга открыта именно на таком месте.;)
Ceci n'est pas un livre.
Для "книги", имхо, важен объем описываемых смыслов и выстроенная логическая структура этих смыслов. Не важно, книга ли это рецептов или "Война и мир" или эпос о Гильгамеше. При этом носитель передаваемых смыслов не имеет значения: электронный файл, папирус, харатья или береста, гранитная стела или глиняная табличка не определяют в полной мере "книгу". На любом носителе может быть любой объем разрозненной информации и это не будет книгой. Как только появляется внутренняя логика, архитектоника - это становится "книгой", не важно как Вы доносите смыслы до реципиента.
Еще одна мысль: аналитикам может быть трудно сразу вербально формулировать ответы, так как работа идёт частота данными, текстом. В процессе написания ответа происходит кристаллизация точного ответа. В то время как устно Вы получите много лишних слов.
Вы зачем в одну кучу смешали листики и текст ? Если описываете внешние признаки классического объекта книга , то смысла описывать содержательные свойства нет. Если содержательное, то тут моменты относительно повесть, статья, рассказ итд
Дык, это же кандидаты себя так позиционируют. У автора требования к способности самостоятельно решать задачи в своей зоне ответственности.
в таком случаи о каких 150-200 кесов может идти речь? :) или вообще работе системным аналитиком, если нет навыков коммуникации на примере тех же определений, к разработчиком тоже относится, олдфаги могут помнить о Джоэле Спольском и вопросе "как бы вы объяснили своей бабушке что такое электронная таблица?".
У автора вполне обоснованная претензия, что полно людей "вайтивайти", которые не очень то подходят для работы тут, при этом еще и губу закатывают. Но у компаний есть дефицит и готовность маяться с такими кадрами, по этому страдают.
Печатное издание.
Я, пожалуй, сделаю наброс.
А вы не думали, что многие резюме кандидатов ваш эйчар отклоняет попросту их не читая? Вот вы и получаете молодых да ранних вайтишников, которым в приоритете бабло а не то что они будут делать руками и головой.
Безусловно, первичный фильтр по стороны HR имеет место. Собеседовать всех кто откликается у меня просто не хватает ресурса - работать будет некогда.
Относительно качества этого фильтра - мне кажется что он достаточно качественный. По крайне мере когда мы обсуждаем пограничные ситуации, то как правило мнение и доводы совпадают. Я считаю HR с которыми работаю профессионалами в своей сфере и отношусь с уважением к их компетенциям.
Безусловно, есть ошибки и 1 рода, и 2 рода. Но не думаю что массовые.
Частая проблема кандидатов – длинная и неструктурированная речь с большим количеством деталей, незначимых для ответа на поставленный вопрос.
Услышав первый затянутый ответ, я переспрашиваю «Правильно ли я вас понял, что…» и повторяю ключевые мысли из ответа кандидата, но раз в десять короче и более структурированно – например, в формате нумерованного списка (во-первых, во-вторых, в третьих
Вот это типичная речевая манипуляция, которую любят детишки. Наговорить кучу бреда вокруг да около, авось что из этого бреда в сознании собеседника сложится куда надо. Самое поганое когда так себя ведут твои коллеги по работе. Еще более поганое когда 90% в команде такие хитровыделанные :)
Это собака, на ней живут блохи и далее про блох ))) Классика
У меня такая коллега-аналитик была, которая на каждом дэйли постоянно "фокусируется", "использует паттерны", "движется в направлении", "делает воркэраунды", а потом оказалось, что просто меньше всех работает
Точно - современные детишки очень часто так говорят.
А ещё я встречал вариант, когда также пишут код. То есть воспринимают код как текст, из которого компьютер сам должен "понять и сделать" то, что требуется.
Я много раз слышал фразу 'да что ты там настраиваешь, программируешь, просто введи данные туда и он тебе ответ выдаст'
Отсюда кстати вытекают вообще проблемы вайтишников которые считают что достаточно чтото выучить и стать программистом, что все решения уже есть в учебнике и их надо зазубрить, а умная машина (вставляем несколько ссылок на copilot и прочие gpt и нейросети) сама все доделает чего не хватает
Все с чего-то начинают, и также юниорам есть место. Некоторые такие идейные, что любого старичка переплюнут
Не очень понял ваше сообщение.
Многие пункты из статьи как раз и показывают отсутствие "идейности" - причем не у "юниоров", а людей с опытом в несколько лет. Которые уже "распробовали" профессию и заявляют о желании дальше в ней развиваться.
Юниоры действительно разные бывают, но это совсем другая история.
Про синтез и анализ это вы круто завернули, у нас было это в универе но вряд ли много у кого отложилось.
Меня больше всего удивляет то, что кандидаты спокойно отвечают на вопрос "чем системный анализ отличается от бизнес-анализа" (т.е. находят различия между ними), но при этом не могут объяснить что такое "анализ" вообще (т.е. не видят сходств - что в них общего).
Про "синтез" часто задаю наводящий вопрос - "обычно анализ противопоставляют синтезу, помогает ли это вам сформулировать определение анализа?"
Объясните пожалуйста этот суходроч в плане запроса определений? Что вам даст словарная формулировка понятия "анализ" от взрослых людей на интервью? Пожалуйста, подробно, как это вам поможет определить качества кандидата как аналитика конкретно в Вашей компании, и то с какой эффективностью он сможет анализировать поставленные задачи.
И причем здесь вообще синтез? Ни разу за 10 лет опыта работы аналитиком не слышал чтобы это слово вообще употребляли в любом контексте.
То, что человек осознаёт суть своей работы (пусть и не зная определений, а может сформулировать своими словами) - жирный плюс:
1. помогает фокусироваться на главном
2. означает, что человек может проанализировать хотя бы свою работу и выделить главное мысль
И то и другое повышает эффективность работы (а второй так и вовсе основной профессиональный навык).
Объясните пожалуйста этот суходроч в плане запроса определений? Что вам даст словарная формулировка понятия «анализ» от взрослых людей на интервью?
А кто просит словарную? Просят обьяснить, что такое анализ своими словами и чем оно отличается от синтеза.
Словарная формулировка, как ответ на вопрос, который ее не предполагал, даст основание думать, что автор ответа - часть "поколения ЕГЭ" (не в смысле возраста). А анализ и синтез - возможно, вам просто никогда не приходилось словами объяснять, на какой стадии находится или в каком направлении идет тот или иной аналитический процесс. Я вот не аналитик, а инженер, но мне значительно проще сказать своему боссу "я на этапе декомпозиции" или "синтезирую модель", чем тратить час на описание конкретных шагов.
Вы серьёзно? Это же обычные слова русского языка, а не какая-то узкая терминология, как вообще можно не знать что они означают?
Придумать само себе правила, а потом расстраиваться, что другие им не следуют. Люблю это
А как иначе? Чтобы подобрать кандидата нужно задать критерии. И обидно тратить время на слабого кандидата.
Дык вроде всё адекватно. Сетуют на узкость кругозора, намазывание CV всякими знаниями, не соответствующими действительности, и т.д. Тут и правил-то никаких нет - обычные критерии - быть адекватным, любить своё дело, знать своё дело. И если любить от миддла никто не требует - то хотя бы знать надо
Ага, у меня есть правило что сотрудники должны быть способны к самостоятельному мышлению. Отказываться от него не планирую. И да, я очень расстроен тем, что не все люди это могут - мир был бы гораздо лучше.
Ага, у меня есть правило что сотрудники должны быть способны к cамостоятельному мышлению.
<trollmode>
Например, самостоятельно придумать на ходу (а не взять то, что уже известно/прочитано), чем A отличается от B. Вместо того, чтобы прямо сказать, что 'не знаю'.
Просто сказать "не знаю" плохо.
В идеале -- попытаться сочинить, признаться в этом и сказать, что пробел будет ликвидирован.
Тут сразу и умение быстро соображать, анализировать и обучаться.
Как я уже писал рядом - я совсем не уверен, что аналитику надо быстро соображать.
У него работа - создавать некие документы, которым потом другие пользоваться будут для работы над чем-то. Так что для меня, как потребителя этих документов получить 'не знаю' от аналитика, тем более неопытного (как тут описываются) - вполне нормально.
Сейчас не знает - пойдет, посидит какое-то количество времени и напишет ответ на поставленный вопрос. Это гораздо лучше, чем получить какие-то сочиненные соображения, начать по ним что-то делать, а потом все переделывать.
По мне так сказать "не знаю" - это как раз признак зрелости и профессионализма
Синтез?🙂
Зачем указывать в ключевых навыках и A и B, если ты понятия не имеешь что это и чем отличается?
Я умею работать и с тем и с тем в рамках моих обязанностей. На моем уровне эти штуки отличаются интерфейсом, но с обоими интерфейсами я свободно разбираюсь.
Из за бестолковых входных фильтров на резюме, что исторически сложились.
У нас в индустрии вообще очень плохо с указанием и названием уровней квалификации - даже если захочешь, не сможешь кратко и универсально-понятно сказать, насколько именно ты чем-то владеешь.
Мир был бы гораздо лучше для кого?
Добавлю и свои пять копеек. Все это непонимание терминологии и её сути имеет корни в том что каждая компания или команда имеет свою версию бизнес-требований, ТЗ, нотаций (произвольно упрощают или усложняют их). И ты в итоге аналитик работает с какими то гибридами, зачастую имеющие связь только в названии со своими прародителями. Плюс к этому ширина ответственности аналитика его компетенций очень разнятся от компании к компании. По итогу многим они пользуются просто как все коллеги во круг, не понимая что это и зачем, просто по причине, что здесь так принято. И многие растут профессионально без плана и структуры развития, а просто из за более усложняющихся задач попутно прокачиваясь. Они даже не догадываются сколько они изобрели по пути велосипедов, сколько раз упустили из виду хорошие практики. Так же набор скилов которые нужен аналитику он не особо поддается стандартизации, нет четких гос.стандартов и программ. В итоге каждый идет своим путем и получается уникальным специалистом с рандомным набором скилов.
По итогу аналитик который должен все систематизировать и структурировать не умеет систематизировать и структурировать свои знания и развитие)))).
Так о том и речь, что аналитику сам бог велел систематизировать и структурировать свой домен, даже если общая ситуация в этой области далека от установившейся ;-)
Есть профессиональные стандарты системного и бизнес-аналитика. Стандарт системного в настоящий момент проходит апгрейд экспертной группой.
20 десятков собеседований - это в среднем 3-5 собеседований в день?
Чего так привязались к прочтенным книгам-то? Я перестал их читать, когда понял, что все новые мысли от 100-страничной книги можно обычно прочитать в оглавлении по пути домой, понять о чем книга и распознаьть, что ты этим уже много лет как пользуешься. Я конечно не аналитик, но все-же...
Вспомнить статью на Хабре? Смеетесь? Я помню пришествие чОрного властелина и... все. Тут технических статей просто нет. Есть коментарии.
Cтатья может быть полезна для кандидатов.
Да. Особенно, если они идут к вам. Разные видения кандитатов у разных интервьюверов. Мне все равно что кандидат читал или не читал, где и сколько работал. Мне важно что он понимает, что конкретно он делал на проекте, что он понимает как работает инструмент c которым он работал и зачем вообще проект существовал.
Это не критика статьи даже, а так наблюдение.
Про книги ваша позиция понятна, но как говорится "есть нюанс".
Если я правильно понял, то вы ПЕРЕСТАЛИ читать книги после того, как поняли что ничего нового из них не получаете. Но многие люди даже НЕ НАЧИНАЛИ их читать.
И это совсем другой коленкор.
там такие нудные книги, взять тот же BABOK - слава суслику, что я не бизнесаналитик
Ну, камон, книги разные бывают. Коль уж помянули Купера - "Психбольница.." вполне бодрая.
А какие-нибудь "Цель" и "Дедлайн" даже чересчур беллетризованы (опять же, вопрос вкуса).
так это же не книга, а индексированный справочник, так и называется — руководство к своду знаний. при этом свод знаний находится в мире, а тут только указатели и определения
Бабок - это книга-справочник, она намного ближе к словарю и энкциклопедии (или документации ЯП), нежели к какой-то литературе где в общем плане описывают концепции или хотя бы Best Practices или разбирают частные кейсы.
Глупо ждать от нее чего-то другого.
просто читаю я список
Про Вигерса, Коберна, BABOK, Леффингуэлла, Фаулера, Купера и прочих классиков
и думаю "ВАВОК. Ничего себе фамилия ..."
а потом понимаю, что это акроним, и вспоминаю, что BABOK-то я как в жизни видел и даже раз один раз открывал (и тут же закрыл :) интересно - сам автор хоть их всех прочитал-то ?)
в общем - решил пошутить, но забыл тег /s
Тем более это аналитик, не программист и не DBA администратор, опыт работы с 2 годами может означать умение запускать клиента в каждой базе и кидать туда относительно простые sql запросы (причем на универсальном диалекте практичеси без использования специфичных фич каждой базы).
P.S. Имхо, нет смысла брать дешевые телефоны на андроиде китайских no-name и удивляться, что ни по одной функции они не дотягивают до последней флагманской модели условного Самсунга.
Просто стоит решить какие параметры вам важнее всего и пытаться получить максимум по ним из того что есть. То есть сравнивать кандидатов с 2 годами с другими кандидатами того же опыта, а не пытаться получить Синьора за копейки. ИМХО.
Ну я же не у каждого кандидата такое спрашиваю - только у тех, у кого в разделе "Ключевые навыки" указаны обе СУБД. Причем человек написал не просто SQL (что чаще было бы более точным), а конкретно Oracle или PostgreSQL - предполагается что он что-то знает и про СУБД.
Меня вполне устроит такой ответ:
Для обоих СУБД я писал только простые SQL-запросы, на таком уровне применения они аналогичны - принципиальной разницы я не заметил. Вероятно, есть какая-то разница в производительности, надежности или еще чем-то, но я не знаю какая именно - это вопрос к ДБА.
Но даже такой редко бывает...
Вот тут в параллельной дискуссии уже разъяснили, что это нормально )
Потому что "сам себя не похвалишь..."
Понятно что могут быть очень глубокие вопросы, причем такие, с которыми далеко не каждый сталкивается. Чисто для примера — я пытался тут на Хабре спрашивать, знает ли кто-то аналог такой штуки, как SCN в Oracle, но для PostgreSQL — не получил ответа. Не исключаю, что нужные люди, которые знают, просто не читали тот пост. Но вопрос реально экспертного уровня, ответ на него просто так не нагуглить. Если человек реально знает ответ — понятно что он скорее всего практически работал и имеет опыт с обеими СУБД.
Да для любого неразработчика главная разница между Oracle или PostgreSQL — в одной конторе купили Oracle или коробочный продукт на нем, а в другом — используют продукты с PostgreSQL под капотом.
Очень маленькое число очень больших контор будет выбирать "а что больше нам подходит", остальные будут использовать (и возможно дорабатывать) некий продукт, который работает с одной из двух этих СУБД.
Так что если аналитик говорит о работе с Oracle и PostgreSQL это не значит, что он знает различия, это значит что он знает интерфейс Oracle Reports Builder и кто там у слонов, я не помню кто там самый модный у слоненка.
Где гарантии, что автор проводит собеседование правильно, особенно на такую сложную и неоднозначную позицию? Я сейчас не говорю о случае, когда автор что-то не понимает во время собеседования, а такое возможно. Я говорю о случае, когда автор понимает, что он говорит, что-то не то. Почему собеседование проведено в правильном формате? Кто присутствует на собеседовании? Только один интервьюер? Или два интервьюера, которые давно знают друг друга, перемигиваются друг с другом? Почему со стороны интервьюеров нет ошибок? В чем ваша уверенность?
Почему этому парню, который принимает на позицию выгодно не лгать? Вы скажете, ему выгодно нанять опытного сотрудника! Вы уверены? В чём его выгода? Почему ему бы не солгать? Что ему мешает?
Допустим, парень, который проводит интервью получает прибавку в зарплате, если сотрудник, которого он нанял, реально очень крутой... А это разве так? Он разве получит прибавку? Почему ему выгодно нанять реально крутого человека?
Вывод: нет никаких гарантий, что интервьюер нанимает крутого специалиста.
Обычно парень, который проводит интервью, получает возможность в дальнейшем переложить часть своей работы на нанятого сотрудника. Поэтому выгодно нанять реально крутого.
Поэтому выгодно нанять реально крутого.
А потому парня уволят нафиг и оставят реально крутого, потому что тот выдает в 3 раза больше. Или реального крутого продвинут в боссы вместо того парня.
Обычно собеседует начальник, имеющий другие абилки, а не равный по должности.
Какие-то вы ужасы рассказываете.
В госконторах и больших фирмах вообще всегда могут назначить начальника со стороны или пересмотреть штатную структуру, это никак не связано с замами и их работой.
а, кстати, и @vedenin1980, и @vadimrоба правы: теория "выжженной земли" вокруг своей должности (особенно, когда большие взрослые ребята подходят к пенсионной планке) - сплошь и рядом. А вот по части "начальника со стороны" - ну тоже, в общем, довольно активная практика. Берете лояльного человека, который потом вам по гроб обязан, поди херово. Ну и да, этот же назначенный"ровно так же выжгет вокруг себя нелояльных ))
Все мои знакомые "офисные военные", которые сами были начальниками, хвалили своих толковых заместителей, потому что кто бы иначе делал за них то, на что они сами забивали.
Конечно. Тем более, на месте заместителя нет никакого смысла подсиживать начальника – плюшки почти такие же, а ответственность гораздо больше.
В моей практике я вообще не припомню, чтобы когда-либо кто-то переместился из замов в начальники того же самого подразделения. Хотя рассказывают, что вообще в дикой природе такие случаи наблюдались.
Наоборот, кстати, бывало – начальник уходил в свои замы.
А начальников набирают из молодых специалистов в кадровом резерве (когда они становятся немолодыми специалистами), либо со стороны.
Начинается новый проект, нужно автоматизировать бизнес-процесс, который сейчас выполняется «на бумаге». Вы идете к заказчику собирать требования.Сперва идете к большому боссу – директору департамента. Большой босс говорит: «мой vision было в том, что …» и начинает рассказывать про космические корабли – искусственный интеллект, нейросети, блокчейн, роботов и т.д.
Вот вы ругаете аналитиков.. вот тут нужно идти к тому, в чью светлую голову пришло "начать новый проект" и к тому, кто выделил на это деньги. Очень часто после этого можно больше никуда не ходить )))
ну и про желаемый уровень ответов на примере сравнения баз тоже метко написали. Аналитику вообще достаточно знать что базы бывают реляционные, и очень понимать что транзакционность. А чем они отличаются и не всякий DBA ответит, это по хорошему пререготива Архитектора выбирать СУБД...
Вот вы ругаете аналитиков.. вот тут нужно идти к тому, в чью светлую голову пришло "начать новый проект" и к тому, кто выделил на это деньги.
Это тоже хороший ответ на кейс :) Найти спонсора/инициатора и спросить что ему на самом деле нужно. И после этого уже принимать решение что делать.
Я ровно про это и пишу - что кандидат прыгает в описанное в кейсе болото и пытается там как-то барахтаться, вместо того чтобы сделать шаг назад и подумать - надо ему вообще в это болото лезть или есть другой путь.
sergeyns, не согласен.
К примеру, в зависимости от того, что нам важнее - целотсность данных или непрерывность бизнеса, нужно выбирать и СУБД, и даже конфигурацию кластера этой СУБД, а также политику фиксации коммитов. И это всё так нефигово аффектит и на железо, и на софт (его опции и конфигурации, внизу-то понятно, что СУБД)
Критичен ли нам простой на два часа? Критичны ли нам потери каких-то транзакций? Критично ли...? Какие данные мы хотим хранить? Как долго? Эти и многие вопросы должен задавать аналитик бизнесу, ответы транслировать архитектору, а архитектор уже сделает выбор и нарисует схему - либо сам, либо с привлечением соотв. DBA.
«Чем отличается А от В? В каких ситуациях лучше применять А, а в каких В?»
А какой ответ вы ожидаете, если на одном проекте аналитик работал с потсгрёй, на другом с ms sql. И там, и там ковырялся в базе? Мне кажется, будет рефлексия на уровне "разные надстройки над стандартом SQL", ещё какие-то мелочи, с которыми сотрудник сталкивался и этого будет достаточно.
Но уж точно не полноценный анализ, когда стоит переплатить за проприетарную СУБД из-за преимуществ 1,2,3.
Насчет "переплатить за проприетарную СУБД" - это ведь сложный вопрос. Надо сравнивать не стоимость лицензий, а совокупную стоимость владения. И здесь уже бабушка надвое сказала что дороже будет.
Про цену лицензии в вопросе вообще лишняя информация, она не имеет значения для ответа.
Тем не менее, какой ответ вас удовлетворил бы?
Мой же пример на основе текста из статьи)
Смотрите, у вас в опыте указаны PostgreSQL и Oracle. И то, и другое – системы управления реляционными базами данных, используются для решения схожих задач. Но PostgreSQL бесплатный, а Oracle стоит миллионы рублей. При этом всё равно находятся люди, которые покупают Oracle. Почему они это делают?
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для Oracle, а вот для PostgreSQL надо нанимать нового человека – его зарплату тоже нужно учитывать. То есть в каждом конкретном надо считать цену, и не факт что Oracle всегда будет дороже PostgreSQL.
По функциональности – на том уровне, на котором я их использовал, СУБД примерно равны – основной функционал РСУБД есть и там, и там. Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал. Плюс вопрос нужны ли они конкретному клиенту. Опять же надо смотреть по ситуации.
По качественным характеристикам – я слышал что Oracle более надежный и производительный, но на уровне слухов. Надо смотреть тесты/обзоры и сравнивать показатели производительности и надежности с требуемыми.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5, а про Oracle говорили давно. Подозреваю, что у Oracle более развитое community и больше специалистов. Это тоже может быть значимым фактором.
Итог - надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.
И вы не ответили ни на "Чем отличается А от В"
Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал
ни на "В каких ситуациях лучше применять А, а в каких В?"
надо в каждом конкретном случае сравнивать СУБД по совокупности критериев
Вода — мокрая. Ответ вообще никакой полезной информации касамео вопроса не содержит.
Помимо цены владения(предположим матожидания), есть еще и риски(дисперсия), и в случаи любой пропритаерщины, они должны идти нулевым пунктом.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5,
PostgreSQL выпустили в 1996 году, и уже лет 10-15 назад ее активно использовали во множестве проектов.
Хорошие и красивые общие слова... Жаль только, что оторваны от реальности. И ваш вопрос про "Oracle vs PostgreSQL", и ответы на него.
Во-первых, Oracle тоже можно использовать бесплатно. У меня есть пет-проект на 11XE, ему много лет, за пределы дозволенного не вышел, и меня все устраивает. А платите вы, внезапно, за поддержку и расширенную версию... И, еще более внезапно, за поддержу постгреса (если вдруг вам нужно) вы тоже платите! Так что "один платный, другой бесплатный" - это вообще неправильный ответ (и вопрос).
И ответы...
Про ДБА, который же есть - ок, остальное про железо - незачет. Вы вообще что с чем сравниваете? "звездолет на Oracle" и "детскую машинку на PostgreSQL"? Нет, вы сравниваете бухгалтерию на Oracle и бухгалтерию на PostgreSQL. И схема данных там и там будет одна и та же скорее всего. И 100500 записей на одной СУБД и на другой будут занимать места плюс-минус одинаково, и обрабатываться тоже одинаково быстро. Разницы в разы - не будет, а на 10 - 20% можно забить. И минимальные требования для оракла копеечные, в конечном итоге: вы просто не купите такой сервер, на котором оракл не запустится (если это только не б/у из прошлой жизни).
Ну, я не знаток функционала постгреса, а вот про оракл могу много рассказать... Не, не примерно равны. Особенно если сравнивать EE с полным фаршем за сотни нефти.
Ну ок, этот пункт норм.
Про постгрес достаточно хорошо слышно уже лет 15, какие 5? Уже тогда было вполне торт (правда, я тогда был молодой и зеленый, могу ошибаться).
Мне кажется вы не учли контекст - "собеседование СА с опытом 1.5-3 года".
Пример ответа выше не претендует на фактологическую точность и не должен быть таковым - ну откуда СА это знать? Это то, что можно сказать на основании общей эрудиции, здравого смысла, базовых знаний SQL и общеупотребимых слухов - что и может быть в голове у СА среднего уровня или ниже.
Если человек не знает, но при этом даёт внятный ответ, при этом четко отделяя факты от допущений - это прямо медаль на грудь и оффер на собеседовании.
P.S. Ну и писать в одном посте сразу "Oracle тоже можно использовать бесплатно" и "если сравнивать EE с полным фаршем за сотни нефти" - как-то странно.
Я учел контекст.
Я так вообще-то не имею ИТ образования. И работать начинал типичным офисным планктоном. Программировать мне нравилось, но я был уверен, что меня программистом не возьмут, потому что профильного образования нет. Поэтому программировал я для себя дома, а работал офисным планктоном. Потом в какой-то момент я решил, что что-то понимаю в компьютерах, и, раз уж не тяну на программиста, пойду в аналитики. У меня даже запись в трудовой есть - "системный аналитик". Так что системный аналитик с опытом 1 - 3 года - это вот вылитый я в молодости.
Как раз в ту пору я начал читать ИТ форумы, а там - бесконечные холивары, какие ОС/СУБД/ЯП/браузеры лучшие, а какие - нет. И там форумные гуру тоже постоянно повторяли эти общие слова про то, что "при принятиии решений нужно учитывать системные требования, нагрузку, количество пользователей" и прочее бла-бла-бла. Я тогда хорошо про себя знал, что знаний и опыта у меня маловато, и молчал в тряпочку. Но все подобные рассуждения мне казались странными. Чего-то в них не хватало. Тогда я думал, что я просто чего-то не знаю и не понимаю. А теперь я вижу, что не зря мне это казалось.
Ну, я не знаток функционала постгреса, а вот про оракл могу много рассказать… Не, не примерно равны. Особенно если сравнивать EE с полным фаршем за сотни нефти.
Так расскажите. Тут уже целый тред собрался за ответом на вопрос за что нужно платить сотни нефти.
Oracle RAC, Oracle GoldenGate, Oracle ADG. Этих трёх за сотни нефти достаточно.
Потому что с помощью внешних инструментов разной степени кривизны это делается, потому и не упомянули. Наиболее популярны комбинации с Apache NiFi / Airflow
В добавок к упомянутому ранее:
Oracle Enterprise Manager
Edition Based Redefinition
Real Application Testing
Oracle Application Express (этот вообще бесплатно)
И еще примерно миллион мелочей, каждая из которых мелочь, а в сумме набегает, что кроме оракла вам нахрен ничего больше не надо:
DBMS_*, UTL_* и прочие пакеты (общим числом под триста штук), за каждым из которых стоит отдельный кусок функциональности, среди которых, например:
dbms_application_info
dbms_aq
dbms_errlog
dbms_ldap
dbms_pipe
dbms_sql
dbms_utility
utl_file
utl_http
utl_mail
ords (появился относительно недавно)
И плюс еще миллион системных вьюх, из которых можно извлечь вообще любую отладочную информацию, которую только можно представить.
Не совсем. Если это нижний сегмент, или что-то более-менее ширпотребное — может оно так примерно и есть. Но в верхнем ценовом сегменте (когда требуется такая же производительность и/или надежность), в том числе например машинок не на Интеле, вас может ждать куча сюрпризов при попытке заменить имеющийся Оракл с железом на другое железо и постгрес. Ну и да, сделайте поправку что спрашивают аналитика, сравнительно неопытного.
Итог — надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.
Ну и будет дальше следующий вопрос «Под какие задачи лучше подходит Оракл за миллионы рублей и почему?» Что дальше отвечать?
попугай научился говорить "зависит от ситуации" и получил работу системного аналитика
А если такой ответ? ))))
Не знаю, кто покупает Oracle в России сейчас, если со 2-го марта 2022 года Oracle прекратил все операции в России.
Но раньше ходили слухи, что Oracle активно покупают за откаты. Правда, я в закупках и продажах Oracle не участвовал, поэтому достоверными фактами, подтверждающими такие слухи, не располагаю.
Разница между этими СУБД — в прогнозируемости пространственного масштабирования?
Учитывая "зарплатную вилку", откликались в основном кандидаты среднего уровня и ниже. При поиске ведущего аналитика с другой "вилкой" ситуация значимо отличалась.
Получается, что вы искали по низу рынка. Кажется, что ваши рекрутеры не очень хорошо собрали статистику.
Вы с одной стороны, как будто экзамен принимаете в вузе "дайте определение анализа", а с другой стороны задаете вопросы философские, ответы на которые сильно зависит от многих внешних и внутренних факторов (типа чем отличается мускул от оракла). Зачем аналитик должен знать чем оно отличается. Не он выбирает базу (а база, выбирает его, как в ДМБ). Вопросы по базам надо задавать дата-инженерам, а аналитик должен уметь находить мосты между разными людьми. Если клиент (внутренний или внешний) под анализом понимает анализы на кровь, значит в проекте будут анализы на кровь
В общем, Вы ищите умного собеседника, с которым интересно поговорить в пятницу вечером под пиво. А не работника, которым будет командовать начальство (а примерно такой Вам нужен)
поиск системного аналитика
Благодарю, очень порадовали!
Тут ведь как: если правильно составлено объявление о вакансии, то придет один кандидат, который Вам и нужен... В Законах Паркинсона все это описано более 70 лет назад.
Теперь про название самой роли для работника (точнее двух ролей, как Вы описываете потом). А если точнее, то там еще более ролей, ибо системный аналитик должен уметь работать по меньшей мере в 5-7 аспектах при системном анализе (аспекты - по ISO 81346).
Очень радует про определения и дефиниции! Если же дать себе труд определить слова "система" и "аналитик" в контексте создания программного обеспечения - то тот, кто сможет это сделать более-менее вменяемо за 10-15 минут скорее всего уже Вам подходит.
Про остальные чудеса и приколы с кандидатами (или почему это почти всегда так):
Основа: кандидаты почему-то считают, что программирование и аналитика - это некое искусство и ему сложно учиться. А это все неверно: системная аналитика, аналитика и программирование - вполне себе сильно детерминированные дисциплины, по которым на 100% все стандартизировано и есть вполне себе типовые методологии, шаблоны и "все уже придумано до нас". И начать можно вполне с ISO 15288, ISO 42010, GERAM и так далее, все давным-давно отработано и описано. И все модели для всех кейсов уже кто-то, когда-то и как-то делал. "Не изобретайте (новое) - лучше комбинируйте (старое)." - девиз всех нормальных инженеров.
Прежде всего, почти всегда кандидаты не знают основы логики Аристотеля. Не только в их формальном выражении, но даже в весьма вольной интерпретации (ну хоть как-то вспомните правила логики...).
Потом, не знают основы кибернетического подхода к анализу систем. Ну и вообще самого системного подхода к анализу реальности. Это не сложно, но необычно, чтобы разобраться и помнить.
Потом плохо различают "процесс" и "продукт". Опять же, все из-за незнания простейших правил логики.
И далее, уже все остальное.
Отсутствие рефлексии относительно используемых инструментов
А тут все хуже: если нет понимания про стандартные методологии и применимый для них инструмент (в рамках того же GERAM) - то зачем вообще выбирать или думать об инструментах? Перед этим неплохо бы выбрать идеологию (методологию) работ. Да и на самом деле, особого выбора то и нет. Все равно все будет построено на тех или иных вариантах системной инженерии, цикле Деминга и объектном подходе. А инструменты под эти идеи похожи друг на друга.
Неумение формулировать определения
Это прямое следствие из 1 закона логики. Не знаем - вот и не применяем. Плюс полное забвение всему, что учили про начальный семантический анализ текста еще в школе. Вопросы "приведите пример существительного, глагола..." И вот уже ступор.
Отсутствие мотивации к самостоятельному изучению профессии
А ее и не может быть на этом этапе. Пока нет профессии - не понятно чему учиться. А когда есть что-то типа "профессии" - то зачем учиться, ведь УЖЕ есть.
Неумение смотреть на ситуацию «сверху»
Не только сверху, но и снизу. Редукционизм и холизм - основа процессов анализа. А если кандидат не может дать определение "аналитик" из названия своей профессии - "чяво уж там, ляпи..."
Короткая память
Обычно следствие малозначительности события. Если сама работа глупая, как и результат - нфига помнить?
Не подтверждаются "ключевые навыки", заявленные в резюме
А это везде и всегда так. Алгоритм подтверждения описан у Паркинсона в "Законах Паркинсона".
Отсутствие понимания что такое «анализ»
А это не так просто, как хотелось бы. Потому и непонятно. Можно сформулировать в разных аспектах, в разных методологиях анализа. Да и чтобы анализировать систему, надо обычно уже представлять (синтезировать) ее модель хоть как-то. То есть разделить анализ от синтеза сложно, а если нет нормальной "гигиены мышления" - то еще все хуже.
Отсутствие реакции на обратную связь от собеседника
Это тоже общая проблема. Цель подготовки учеников в школе и начальном ВУЗ - формирование легкой формы олигофрении в каждом ученике. Такие люди - ценный ресурс для осуществления некритичных покупок любого товара. Так во всех странах, это не феномен России.
Нет планирования своего профессионального развития
Ключевое тут слово "планирование". Обычно нет никакого планирования ни в каком аспекте жизни. Вместо "акции" - только "ре-акция" (после акции, ответ на акцию). Почему так - тоже вполне понятно, описано пунктом выше.
Чего им чаще всего не хватает, какие вопросы вы задаёте?
Чаще всего не хватает именно базовых основ логики и семантики - "гигиены мышления". Остальное - можно быстро научить. Но обычно "гигиена мышления" заменена на кучу из обрывков мифологии, мнений старших, идеологии и прочего шайза на уровне архетипов... И поменять это все - очень сложно, потому как вбито глубоко и основательно. Да и небезопасно для человека, с социальной точки зрения.
зачитался вашим комментарием и выписал из него многое для изучения, благодарю
Комментарий мощный, спасибо.
Признать я так далеко не заходил, и всегда считал GERAM и иже с ним не применимым на практике отвлеченным умствованием.
Но возможно я не прав и при достижении определенного уровня осознанности приходит понимание его роли и смысла.
Благо дарю!
Насчет GERAM, TOGAF, всяких там RUP UML и прочей фигни: это не сложно.
Обычно проблема в понимании подобных методологий происходит из одномерности классификации (в голове). Если более научно, то обычно аналитик пытается построить в голове одну упрощенную линейную модель в метафоре "листка бумаги". То есть "кубики и стрелочки на одном листке бумаги." Это двумерная модель, в идеале построенная по такой же "двумерной" логике Аристотеля.
А все современные методологии используют "трехмерную" модель классификации, некую "трехмерную логику". Это не совсем точная метафора, но важная для понимания.
Аналогия с инженером и чертежами на бумаге. По таким чертежам надо построить трехмерную деталь. А можно сразу создавать трехмерную модель детали, но на листке этого сделать не выйдет.
С системным подходом примерно так же: каждый аспект в системном подходе - это двумерная часть модель. Причем всегда неполная. А модель системы в целом - многомерная (по количеству аспектов). И эту полную модель никогда и никто не увидит и не поймет. Но это и не нужно, потому как работаем всегда с двумерными моделями.
Как это сказывается на логике? Работа сразу в многомерной классификации (в полной модели) приводит к нарушению важного правила логики Аристотеля. "Не противоречь сам себе". Или: в отношении одно объекта в одно и то же время не может быть двух противоположных суждений. А в многомерной модели - может. В двух разных аспектах - такое может быть. Это одна особенность, но их много.
Вроде все просто, но принять и понять особенности такого подхода - крайне сложно. Поэтому обычно пытаются приспособить все эти методологии к плоскости логики Аристотеля. А не выйдет. Надо переделывать свой мозг и восприятие. И тут ступор. Лично мне потребовалось 12 лет и 1 час. Причем 12 лет бился как баран головой в новые ворота - и никак. А потом - за 1 час все стало кристально ясно и понятно.
Сам такой переход - очень важен, очень упрощает всю работу далее. Реально за 2-3 недели я потом спокойно разобрался с GERAM , методами RUP и разными методами системного анализа. Но без такого перехода - ну никак. Это мой опыт, может бывает и иначе.
Тут ведь как: если есть опыт и образование по классическим методам, не по системным - то трандец полный. Тогда еще сложнее переключить разум с "плоскости на трехмерку."
С моей точки зрения, именно такое переключение - самое важное. А потом можно все изучить и работать по современным системным методологиям. Тут не уровень осознанности важен, а совсем иной вид осознания.
А самое фиговое: я точно знаю как жить и работать в таком системном подходе, классический подход тоже можно использовать, но! Но как "переключить" или научить кого-то, чтобы он тоже так мог делать - не понимаю и не знаю. Несколько лет пробовал с разными специалистами, получается иногда, но крайне редко и нестабильно.
Поэтому GERAM и иже с ней - это все несложно, применимо на практике. Если что-то не подходит - всегда можно доработать или переделать. И для этого не надо каких-то сверх знаний или умений. Аккуратность, минимальная "гигиена мышления", немного книжек - и все работает.
Да-да-да, интервьюер, критикуя, совсем сам не упомянул кибернетику, с которой все и можно было бы начать для специалистов начинающих.... Дать пару кейсов на логику и попросить озвучить ход мысли. На этом все.
Сложилось впечатление, что вы ищите "человека разумного", а для этого необязательное вскрывать, есть ли за буквами в резюме реальный бэкграунд, или это миф.
Более того, не на все ваши вопросы даже стоит отвечать. Например: разница между СУБД. Я бы сказала, что всегда приходится выбирать в конкретных условиях, и предполагать, почему в тех или иных условиях сложилось то или иное решение бессмысленно, разве только в учебных целях.
Про "отсутствие реакции на мои невербальные посылы" - ну..... В условиях стресса, если не хватает ресурса, важнее думать и отвечать, чем реагировать. Будьте щедрее :))
Ну и, конечно же, это не статья, если уж мы боремся за чистоту терминов и соринки в своем глазу замечаем.
В целом, спасибо, очень интересно.
Это вы еще про аббревиатуры кандидатов не спрашивали, коих может быть много в резюме. Причем не обязательно расшифровку просить, иногда достаточно спросить: а что это?
А вообще я понимаю ваши вопросы. Кандидат может не знать в чем разница между Oracle и MSSQL, но ответ на вопрос покажет как он размышляет и есть ли у него банальное любопытство: почему была выбрана та технология, а не иная.
Определения — это плохая идея. Дать определения очевидных и базовых вещей иногда бывает практически невозможно. Вот попробуйте-ка дать не само-рекуррентное определение "множества". Вроде как понятно — набор элементов. А что такое "набор"? В итоге практически никто вам внятного определения не даст.
Ну это вы прямо в онтологию пошли.
Да, можно взять набор базовых терминов, объявить их самоочевидными и дальше из них конструировать остальные определения. Но это уже в отвлеченную науку пошло.
Но так далеко я не захожу, ограничиваюсь только одним уровнем. И прошу определения только для тех терминов, которые могу определить сам.
Давайте конкретики. Вас устроило бы следующее определение "требования к ПО — это формализованные пожелания заказчика к финальному продукту"?
На троечку, если честно.
Пожелание - это примерно то же что и требование, только необязательное к исполнению.
Отлично. Какое же определение "требования" вам на пятерочку?
"требование" — это и есть такое же основопологающее понятие, как и "множество". Вы его не через синоним фиг опишите.
Нет идеального определения, каждому нравится свой вариант. В BABOK своё определение, в книге Вигерса приводится своё, у Леффингуэлла своё.
С моей рабоче-крестьянской колокольни удачным кажется определение "Требование к ПО - это описание функции или свойства, которым должно обладать разрабатываемое ПО". По крайне мере мне из этого определения понятно что такое "требование".
это примерно то же что и требование, только необязательное к исполнению.
Вот выше @vk220указал, что «требование» характеризуется словом «должно», я же утверждал бы, что эти слова в целом используются взаимозаменяемо (вопрос об источнике требований не рассматриваем, потому что иначе определение перестаёт работать).
Получается, что в данном определении нетривиальным местом являются «описание функции или свойства» и «разрабатываемое». Второе понятно (хотя мне как не аналитику неочевидно), но первое-то что значит? Что ещё, кроме функций и свойств, может быть у разрабатываемого ПО, чем она должна обладать, но при этом что не входит в требования к ПО?
Словом, в наивном определении множестве не скрывается невнятность, но она хотя бы прозрачная, без лишних слов, напускающих туман. Я, конечно, мимокрокодил; может, у вас принято так, но выше многие упоминали про важную роль логики, поэтому и откомментировал это безобразие.
Категорически не согласен.
Во-первых, если взять обычное ГОСТовское ТЗ, то там помимо функций и свойств изделия есть ещё масса требований: порядок разработки, стоимость, порядок приёмки и т.д. и т.п.
Во-вторых, требование совершенно не обязательно формулируется в виде описания. Оно может быть, например, отсылкой (“в соответствии с ГОСТ ISO 23409-2014”). Или производной функцией (“чтобы шеф был доволен”). А могут быть вообще неявно подразумеваемые требования.
Солидарен с коллегами, которые считают, что “требование“ – базовое, неопределяемое понятие. Можно сказать, что требование – это ограничение, но это, на мой взгляд, просто игра словами.
Из перечисленного в статье, мне показался имеющим глубокое практическое значение вопрос об отличии PostgreSQL от Oracle, но это вопрос архитектора, а не аналитика.
Порядок разработки или порядок приемки - это не требование к самому ПО, это требование к процессу его создания. Их принято разделять. Требования к процессу создания ПО - это менеджерская история, аналитику они скорее для информации.
В вашей точке зрения есть своя правда. Но в том же babok или у Леффингуэлла определение термина "требование" приводится.
Их принято разделять.
ГОСТ тут с вами не согласен. И в этом есть глубокая жизненная правда, потому что многие свойства изделия определяются именно технологией его разработки и производства.
Что касается BABOK, то я не отношусь к его поклонникам. В нём очень много пустого умствования, на мой вкус.
Если вы про ГОСТ 34, то он на автоматизированные системы, а не на ПО. Поэтому ТЗ по ГОСТ 34 содержит много того, что не является требованием к ПО. Что вполне логично. Если про ГОСТ 19, то я признаться уже не помню что там в ТЗ.
Понятно что это тема для отдельной дискуссии.
Да неважно, хоть ГОСТ 15 :) ПО на самом деле не очень-то отличается от прочих изделий с точки зрения предъявления требований. Более того, именно участие в разработке “железа” помогло мне более хорошо понять разработку ПО.
Единственная по-настоящему существенная особенность заключается в том, что стадии разработки ПО не очень хорошо ложатся на классический инженерный водопад, откуда и возникли всякие аджайлы. Но это имеет отдалённое отношение к предъявлению требований.
Требования (к ПО, системе и т.д.) по ISO 29148 и ТЗ на разработку ПО / ТЗ на создание АС — это вообще разные по характеру документы.
Требования к ПО — это требования к результату деятельности (объекту закупки-разработки-поставки-монтажа-настройки).
ТЗ на разработку ПО / создание АС — это ЗАДАНИЕ на РАБОТЫ. В задание на работы как правило входят как требования к результату, так и требования к процессу, очерёдности, срокам и т.д.
Давайте с вами начнём с того, что такое, по-вашему, ПО?
я вот тут делал разбор стандартов
Ограничение — это разновидность требований.
В системной инженерии требования разделяются на требования к способностями объекта требований и ограничения.
Изучайте системную инженерию, выходите за рамки узкого мира ИТ.
В системной инженерии требования разделяются на требования к способностями объекта требований и ограничения.
выходите за рамки узкого мира ИТ.
Охотно. Давайте обсудим, чем отличаются требования к холоднокатаной стали от требований к горячекатаной. Вы, вроде, выше написали, что требования к процессу и объекту - принципиально разные вещи?
А в качестве вопроса со звёздочкой предлагаю обсудить, чем отличаются требования к зелёному водороду от требований к оранжевому водороду.
Есть такая вещь, как технология.
за рамки ИТ — это значит, давайте поймём хотя бы, что кроме требований к оборудованию и ПО, есть хотя бы требования к деятельности людей и к организации в целом, как системам более высокого уровня
см. например ISO 29148 — основной международный стандарт по инженерии требований, он выделяет как минимум 4 уровня требований при создании систем (не ИТ-систем, любых):
Business Requirements
Stakeholder Requirements
System Requirements
Software Requirements
Это не ответ на поставленный вопрос.
Эти все рассуждения хороши, когда процесс создания изделия технологически примитивен, например, когда речь идёт об информационных системах. Где главная сложность именно в том, чтобы разобраться в самой постановке задачи. А огромное количество задач (в том числе и в IT), напротив, имеют очень простую постановку при очень сложном решении.
да, я писал, что требования к результату и процессу — это требования к разным объектам
приведите пример, о каких задачах речь, чтобы лучше понимать
"Во-вторых, требование совершенно не обязательно формулируется в виде описания. Оно может быть, например, отсылкой (“в соответствии с ГОСТ ISO 23409-2014”). Или производной функцией (“чтобы шеф был доволен”). А могут быть вообще неявно подразумеваемые требования."
В системной инженерии требованиями считаются утверждения о свойствах объекта, согласованные участниками деятельности.
"В соответствии с ГОСТ XX " — это не требование целиком, а только его атрибут — источник. Изучайте руководство по разработке требований INCOSE, оно даже на русском есть.
"Чтобы шеф был доволен" — в соответствии с системной инженерией, это не производная функция, а требование стейкхолдера или даже требование надсистемы.
"Неявно подразумеваемые требования" — если они не согласованы сторонами, то это что угодно — ожидания, идеи, мысли, но не требования.
А разве в вопросе было что-то про системную инженерию?
"Чтобы шеф был доволен" — в соответствии с системной инженерией, это не производная функция, а требование стейкхолдера или даже требование надсистемы.
И здесь вопрос в данном случае не в том, из надсистемы или откуда ещё это требование возникает, а в том, каким образом оно сформулировано.
Вы можете, конечно, сказать, что ваша священная книга запрещает формулировать требования таким образом, но это никак не отменяет того факта, что перед нами вполне имеющая смысл в реальной жизни формулировка, не сводимая к принципиально другим. АРМ Главного Босса – не такая уж редкая в природе вещь.
я к тому, что это тоже форма требований, просто к другому предмету, а не "производная функция"
другое дело, что ничего полезного в именной такой формулировке нет, т.к. требование низкого качества
потому что, опять же, шеф скорей всего будет доволен не столько системой и даже не проектом, а проектом и результатом применения системы
и всё это квалифицированному аналитику надо расшивать в конкретные формулировки, не оставлять свёрнутым клубком
В числе прочих критериев требований (а не желалок стекхолдеров) есть и такие: однозначность и выполнимость. Вот это ваше "что бы шеф был доволен" - никак не подходит.
А так-то, требования - список желаемых свойств объекта; при этом эти свойства должны соответствовать определенным критериям.
Т.е. понятию требование соответствуют не любые свойтва объекта, которые вы хотите получить, а лишь сформулированные определенным образом.
Не знаю, насколько это соответсвует кому-либо из канонических описаний требований.
//ни разу не СА
Если задача сложная, то выполнимость, а тем более однозначность, может быть непонятна заранее. Из чего следует, что такое требование к требованиям - тоже желалка.
По ГОСТу, как раз для уточнения выполнимости и однозначности требований служат этапы эскизного и технического проектирования. (Из чего, конечно, не следует, что после этих этапов всё обязательно становится волшебно хорошо).
Понятно, что аналитик должен подготовить описания функций и свойств системы, которые потом кто-то каким-то магическим образом реализует.
Окей, критерии качества требований, процессы управления ими и прочее оставим за скобками, но вот вам пример требования под ваше определение:
У системы есть функция close, которая завершает все текущие процессы с таймаутом в 10000 мс и закрывает приложение.
Таких требований можно автокомментариями по коду нагенерировать, зачем здесь аналитик?
Лучшее определение, которое я видел в жизни - это определение "переправы" в Уставах. Как сейчас помню - "переправа - это участок местности, оборудованной для переправы". А вас тут синонимы не устраивают, видите ли.
А мне нравится "квартира" и "многоквартирный дом" в ЖК РФ:
Многоквартирный дом - здание, состоящее из двух и более квартир
Квартира - помещение в многоквартирном доме
По отдельности каждое определение выглядит нормально, а вместе какая то рекурсия.
сепульки навеки в наших сердцах!
а вместе какая то рекурсияИ что здесь плохого? Определения всегда будут иметь рекурсивную природу. В отличии от смысла понятия.
наличие незавершающейся рекурсии не позволяет отличать доказательства истинных утверждений от доказательств ложныхЕстественно, в этом и есть слабость логики (не знаю какой смайлик ставить — грустный или веселый).
Запретить незавершающуюся рекурсиюНе совсем понятно как отличать конечную рекурсию от незавершающейся до ее начала.
рассматривать только индукцию (которая та же рекурсия, вид сбоку)Не понял аналогии между рекурсией и индукцией. Речь про бесконечную индукцию?
рассматривать только индукцию… по фундированным множествамНу то есть мы работаем с входными данными — если они структурированы, то все ОК, а если нет?
Я не сомневаюсь в большом количестве внешних условий, при котором незавершающаяся рекурсия невозможна, вопрос — насколько нам удастся эти условия выполнить.
что гарантируется вещами вроде такихК сожалению этот материал выходит за пределы моего знания как англоязычной математики, так и просто знания математики.
Нет, это не рекурсия, а нечто близкое к "порочному кругу". Но логической ошибки тут нет. Она была бы если бы определение звучало как
"Квартира - составная часть многоквартирного дома".
Смотрим, однако Федеральный закон от 30.12.2009 N 384-ФЗ (ред. от 02.07.2013) "Технический регламент о безопасности зданий и сооружений", п. 14 ч. 2:
помещение - часть объема здания или сооружения, имеющая определенное назначение и ограниченная строительными конструкциями
Таким образом, читая нормы в совокупности, можем сказать, что определение постулирует, что квартирой является помещение именно в многоквартирном доме.
Т.е. пристроенный открытый навес к деревенскому дому "на две семьи" - не квартира (не является помещением, т.к. не ограничен строительными конструкциями); с остекленной верандой ситуация сложнее, ее можно, наверное, отнести к одной из квартир :)
Ну и помещение отдельно стоящего дома "на три окна" - не квартира (дом состоит лишь из 1 помещения, т.е. не многоквартирный).
А пятистенок многоквартирный или нет? в нем есть 2 помещения. (обычно правда их считают за комнаты, а не квартиры, но они точно помещения из определения выше)
Нет смысла вести дискуссию исходя их искаженных определений (а топикстартер их исказил, процитировав частично).
Читаем, как на самом деле написано в ЖК РФ:
ЖК РФ Статья 16. Виды жилых помещений
1. К жилым помещениям относятся:
1) жилой дом, часть жилого дома;
2) квартира, часть квартиры;
3) комната.
2. Жилым домом признается индивидуально-определенное здание, которое состоит из комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком здании.
- здесь есть комнаты, нет квартир.
3. Квартирой признается структурно обособленное помещение в многоквартирном доме, обеспечивающее возможность прямого доступа к помещениям общего пользования в таком доме и состоящее из одной или нескольких комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком обособленном помещении.
то есть квартира
а) это структурно обособленное помещение
б) имеет прямой доступ к помещениям общего пользования (т. е. если есть комната + санузел + кухня, но все это выходит в другую комнату, а не на лестничную клетку или общий коридор - это не квартиране может квартира иметь выход в другую квартиру)
в) состоит не только из комнат(ы), но еще из вспомогательных помещений.
4. Комнатой признается часть жилого дома или квартиры, предназначенная для использования в качестве места непосредственного проживания граждан в жилом доме или квартире.
Таким образом, насчет пятистенка - ответ зависит от проекта, смотря какой пятистенок. Но если выход на улицу один - то речь о квартирах идти не может, только о комнатах/вспомогательных помещениях.
Кстати, квартиры в старых советских деревенских дома "на 2 семьи" не вполне удовлетворяют определению квартиры по ЖК РФ, т.к. выходы у них не в помещение общего пользования, а на улицу. Ну и нумерация часто бывает вида дом №50а и №50б, а не д. №50 кв 1 и д. №50кв 2. С другой стороны, д. №50а и д. №50б тоже сомнительно выглядит, т.к. жилой дом - это "индивидуально-определенное здание" (надо разбираться, что это значит точно).
а топикстартер их исказил, процитировав частично
Процитировал в той части, чтобы стало очевидным что в определении термина А используется термин В, а в определении термина В - термин А. Это настолько же странно, как доказывать теорему А на основании теоремы В, а теорему В на основании теоремы А. Остальное для сообщения было незначимо.
На дальнейшую дискуссию про пятистенки, признаться, не рассчитал :)
Нет, в данном случае - это нормально. А вот упрощать нормы при чтении - неверная и опасная практика, которая приводит к проектированию систем - если только мы ведем их прямое нормативное проектирование - исходя из неполных и неверных моделей. Я с этим неоднократно сталкивался и тоже учился на своих ошибках.
Вы ссылаетесь на теоремы, могу предположить что базовое образование у вас - математическое. Но методы мышления, которые вырабатывает математика, к НПА нужно применять с осторожностью. Юридические определения не отвечают критериям, которые приняты у математиков, и нормы не излагаются в линейной дедуктивной последовательности, как аксиомы и определения у Евклида. Хотя формальная логика одинаковая.
Например, при внимательном прочтении ст. 15 и ст. 16 ЖК РФ, которые вас так зацепили, можно увидеть, что у этих статей вообще говоря, различные по существу цели. В ст. 15 законодатель определяет объекты жилищных прав и некоторые аспекты их жизненного цикла, а в ст. 16 - дает классификацию жилых помещений. То, что две изначально разных конструкции, пересеклись по понятиям "многоквартирный дом" и "квартира" - в данном случае скорее не порок определений, а следствие того, что квартира выступает и как частный случай объекта жилищных прав, и как частный случай жилого помещения.
А кажущаяся кольцевой ссылка между А и В выражает лишь созависимость этих понятий, т.е. квартира не может существовать иначе как в составе многоквартирного дома, и многоквартирный дом не может существовать иначе, чем как здание, состоящее из квартир и имущества, определенного корреспондирующей нормой - п. 1-3 ч. 1 ст. 36, которая также упомянута в ст 15. И вот эта корреспонденция со ст. 36 является очень существенной.
Если вы начнете выписывать структуры норм последовательно и логично, то увидите, что их понятийная схема с учетом корреспонденций значительно сложнее, чем режущая глаз созависимость А и B.
Рекомендую почитать Оробинского В.В. "Чему не учат на юрфаке" (лучше брать сразу "Чему не учат на юрфаке, расширенное и дополненное издание", там три книжки под одной обложкой), у него там были хорошие главы о стратегиях мышления, устройстве норм и их трактовании.
что хорошего в этом определении?
тут явно перепутаны 2 омонима — участок местности и деятельность по перемещению с одного берега на другой
определение "переправы"
По-моему, любое определение станет идеальным если к нему добавить оконцовку ", и ниипёт!". Вот попробуй прочитать вслух всё вместе - лучше же стало, а?! :)
Ну вы загнули. Даже в курсе университетской математики (матан, матлогика), множество - базовое, фундаментальное, единственное неопределяемое понятие (всё, что пытается его формализовать - аксиоматика теории множеств, но это не определение), все остальные сущности (числа, отношения, функции) определяется через множество. Так что, мне кажется, попытка дать хоть сколько-нибудь строгое определение множеству "с потолка" обречена на провал.
Еще можно вспомнить про существование множества всех множеств, которое при этом не является подмножеством самого себя.
Вопрос множеств действительно ключевой в математике.
"Множество" — это самый яркий пример. Так-то дать определение числу — тоже сложно. Про какую-нибудь аксиоматику Пеано далеко не каждый знает. А понятие очень базовое. Тоже самое со "сложением".
Дать определение для базовых вещей — часть очень и очень сложно. Поэтому тут столько простора для субъективизма и демагигии, что я считаю это очень плохим вопросом на собеседовании.
Основная сложность (точнее, невозможность) возникает при попытке дать логически и математически строгое определение. Это, действительно, невозможно - точка, число, множество и что-то ещё являются неопределяемыми понятиями. Однако на практике просьба "дайте определение" не подразумевает этого, поэтому в таких бытовых определениях вполне могут быть более или менее синонимичные или рекурсивные термины. Например:
точка - неделимый и не имеющий размеров объект, из множества которых состоят все геометрические фигуры;
множество - неопределяемое понятие математики, изучаемое в теории множеств;
число - математически точная количественная характеристика величины предмета или выраженности свойства.
Теперь мне, как системному аналитику, попадающему под те параметры, которые описаны в статье, хочется пройти техническое интервью у Вас!) Но не ради трудоустройства, а интереса ради)
Хотелось бы отметить, со всем уважением к автору и другим авторам подобных статей, что рассуждения о том, как убедить соискателя (продавца) хотеть меньше не очень красиво выглядят, когда их пишет потенциальный покупатель (наниматель). То есть, в первую очередь, хочется видеть в интервьюере понимание того факта, что продавец хочет продать подороже, а покупатель хочет купить подешевле.
Убеждать продавца продать подешевле ничуть не лучше, чем убеждать покупателя купить подороже. Это противоречит интересам сторон. И я понимаю, что покупка способности к труду это вынужденная покупка особого рода, поэтому и оплачивается уже после получения вторичных ценностей в результате осуществления этого труда. Но, равно и продажа труда это почти всегда ход вынужденный, направленный на физическое и социальное выживание.
Поэтому вменять продавцу, что его житие-бытие стоит дешевле, а то и ничего не стоит, просто потому что А, Б, В и пункты со звёздочкой, это как-то лицемерно. Ведь мы наверняка не знаем, что и чего стоит, пока не произойдёт вторичный обмен ценностями. Рыночного акта ещё не случилось, и, вполне может быть, что это вы мало даёте за озвученный список требований.
В общем, некрасиво как-то НЕ говорить "я не могу на тебя столько потратить", а от лица всей вселенной рыночно-трудовых отношений заявлять "вы столько не стоите".
Если я правильно понял Ваш комментарий, Вы апеллируете к морали нанимателя? Только и исключительно к ней?
Скорее к бытовой этичности сторон.
Сомнительно, что можно говорить о "бытовой этичности", когда речь идет о деньгах. И об игре с той самой "нулевой суммой".
Для бизнеса более-менее корректно, что нулевая сумма это дележ доли рынка между конкурентами. А в чем нулевая сумма для работников-то? Даже если мы берем фиксированный ФОТ, можно было-бы говорить о нулевой сумме между работниками, но они чаще всего никак не влияют на его распределение. Работник приносит какую-то ценность бизнесу (даже если это уборщица и продавщица), за это получает деньги, если ценности нет, то и платить деньги не за что.
Да, опять же, я не стремлюсь к декларированию этики всем вокруг, мне скорее хотелось бы в подобных ситуациях для всех участников (или для тех, кто описывает ситуации подобные этой) открытости и понимания, зачем они тут собрались и у кого какие интересы.
Например, чтобы условный студент или джун понимал вероятность (только вероятность) того, что его оценивают не по фактическим знаниям, а по тем изъянам, за счёт которых можно сбить цену, хотя бы на первые полгода вписать этого кадра в свою юнит-экономику. Чтобы отказ не воспринимался за полную и прямую оценку своих умений. Наверное, демотиватора лучше и не найти.
Конечно, тут же хотелось бы и для работодателя понимания, что совсем втаптывать молодых специалистов в грунт не очень полезно для дальнейшей жизнедеятельности соискателя, ведь он не просто от скуки пришёл поработать, у него пик фертильности, ощущение начала взрослой жизни и т.д. Полезность прикорма никто не отменял, даже если вы циничный мизантроп.
То есть, за любой прямотой и этичностью можно увидеть какую-то (на мой взгляд) взаимную выгоду. Хотя, наверное, это всё применимо для растущей экономики, а в наших палестинах война всех против всех за бОльший кусок всё меньшего пирога и латание экономических дыр дешёвым чужим мясом, сорванным без всякой этичности.
а в наших палестинах война всех против всех за бОльший кусок всё меньшего пирога и латание экономических дыр дешёвым чужим мясом, сорванным без всякой этичности.
Наконец-то описание без розовых очков. В РФ человек человеку волк. У программистов, наверное, было иначе - за счет спроса со стороны Запада, этот спрос провоцировал перманентный дефицит кадров. Но приходят новые реалии.
А можно немного предложения-почти троллинга от потребителя работы аналитиков?
Проводите все собеседование в письменном виде, а не голосом. Потому что насколько хороший аналитик - это видно по тому, насколько он хорошо описывает и объясняет все что нужно для других людей. В том числе - для других, которые появятся, когда самого аналитика на проекте уже не будет. Лет так через 10 после начала существования проекта.
Ага, для этого раньше использовались тестовые задания - посмотреть как человек пишет.
Сейчас, к сожалению, люди редко соглашаются делать тестовое, и этот этап отбора пришлось опустить.
Не так. Речь не про тестовое задание. Вот что тут в статье было?
«Чем отличается А от В? В каких ситуациях лучше применять А, а в каких В?»
Вот пусть напишет ответ, подумав полчасика и поползав по справочникам. Такой, чтобы прочитав его, стало понятно, A мы сейчас должны использовать или B.
Потому что мне, скажем, совершенно неочевидно, что аналитику надо это различие сразу в голове держать (для беглости ответа), а не выдавать полный результат через некоторое достаточно большое время размышления и подготовки. Важнее, чтобы потом (возможно, когда аналитика уже не будет), у меня не появлялось желания задавать уточняющие вопросы по этому ответу 'а почему вот это-то выбрали?'
Потому что риск несоразмерен
Потратить эдцать часов, чтобы что?)
Лучше сходить на 5+ собесов, после них кто-то работу да даст.
В прошлый раз я сделал тестовое на 40 часов, обратной связи не было вообще :)
Странная статья. Открывается вакансия на 2 в 1: бизнес-аналитик + системный аналитик. Нигде в контракте мелким шрифтом не написано, что когда уборщица заболела, то еще надо и туалеты помыть раз в неделю? Ставится зарплатная вилка, на которую откликаются только мидлы, причем мидлы или только бизнес-аналитики, или только системные аналитики, а на вопросы по второму профилю ответы придумывают на ходу. Ответ простой: надо или брать двух мидлов, каждого в пределах этой зарплатной вилки, или увеличивать зарплатную вилку в 2 раза и надеяться, что клюнет кто-то толковый. Есть еще третий вариант - валить с конторы, где такие нищенские бюджеты, т.к. если новеньким обещают такие скромные деньги, то старожилам точно не стоит ожидать повышения з/п.
Потому что системное мышление отсутствует у большинства чуть менее, чем полностью.
Все слишком профильными стали и не могут видеть что-то выше своего круга задач.
что именно вы называете "системным мышлением"?
Вспоминается...
Вчера на собеседовании спросила: «А почему ваш прошлый работник уволился с этой обалденной должности?» Ощущение понравилось, всем рекомендую.
с хорошей работы срочно не релоцируются; так что у вас не так-то? :)
Внезапно, я вас поддержу: хороший работодатель (предполагается) должен ценить шкурку своего работника. От того, что его заберут на фронт, лучше работодателю не станет.
Если же нет, то:
1) работодателю плевать на работников, и за забором - очередь, а денежные и не-денежные потери от потери работника (путём выемки оного на фронт) несущественны.
2) работник настолько неважен (сам по себе, или в рамках исполняемых обязанностей), что если его заберут, то появится удобный повод найти нового или закрыть ставку.
Оба варианта, честно говоря, не очень. У меня тут знакомый сеньор сбежал за границу, а компания сказала, что правила есть правила... и эти правила важнее, чем страх сбежавшего сеньора за свою жизнь, ну или незакрытая ставка в офис (кек).
Собеседование в текущее время это уже немного необычно. Те кто не уехали из РФ - вряд ли будут сейчас менять работу (только те, чьи компании уехали, а они остались). А те кто уехали вряд ли будут отдавать приоритет вакансиям с оплатой в рублях.
Более того, есть разные факторы почему к вам не идут те кого вы хотите видеть. Многие мидлы и сеньоры не хотят идти в стартапы (семья, дети, ипотека и т.п. - им бы просто получать много денег в стабильной компании). Многие не хотят идти работать на галеру (хотят работать в продуктовых компаниях). Дальше, есть те кто не хотят работать в госах или если ключевые заказчики госы (бюрократия, этические соображения и т.д.)
Итого, выставляете вроде бы неплохую вакансию вроде бы за рыночные деньги, а никто не идет, потому что не хотят идти в галеру с госзаказчиками.
Все что описал, в разные моменты времени испытал на себе (как интервьюер, работавший в разных компаниях)
Да все путем конечно и по делу написано, но если человек уже может ответить на все вопросы что в статье озвучены, то это уже ближе к сеньёру. Даже большинство мидлов могут многих вещей не знать.
Во первых, давать определение терминам - задача Бизнес-Аналитики, мы создаём "карту" в т.ч. терминов, по которой потом все ориентируются, СА делают тоже самое для системы - добавляют процедуры, поля, параметры и т.п. Надо всё же указывать, что у вас аналитик совмещает БА и СА. Кстати за одно такое совмещение уже надо нехило доплачивать, если у человека и то и то получается на соответствующем квалификации уровне. 150 тут нижний край для джуна-СА-БА, а если СА или БА доведен до уровня мидла, то тут уже надо 250, т.к. мидл-БА может 200 получать не залезая в систему (СА наверно тоже).
Знать "на зубок" отличия технологий, протоколов и т.п. должен архитектор (системный, если мы о примерах в статье), это уже от 500. Сеньор должен знать особенности. Собственно накопление и систематизация знаний об особенностях различных архитектур и позволяет из сеньора системного аналитика стать системных архитектором.
И чисто моё наблюдение: люди которые хорошо знают СА и БА как правило редко сидят в анализе и идут в управление, т.к. могут "и там и там" работу контролировать и управлять ей. У нас из 20 бизнес-аналитиков только 2 могут ещё и в системный анализ, было бы больше, если бы постоянно не уходили "на повышение".
Бизнес-аналиТИКА вообще занимается анализом показателей деятельности организации за прошедший период.
А бизнес-аналиЗ занимается исследованием сиутаций и проблем в организацией и поиском, обоснованием и контролем реализации решений проблем.
Системному аналитику как минимум приходится разбираться в предметной области и в ходе этой работы само собой строить онтологические модели, в том числе для поддержки их в софте через DDD. А не только "добавлять процедуры и поля".
Не совсем знаю, какая ситуация в отдельно взятой компании, в которую проводится собеседование.
У нас на рынке труда, работа аналитика сильно заходит в смежные области, особенно при решении разовых задач, для которых не всегда имеет смысл выделять штатную единицу:
- В область ПМ-а (согласуй эти сроки с заказчиком; обзвони всех разработчиков смежных ИС и уточни - устраивает ли их протокол обмена).
- В область технического писателя (опять-таки, составление техинструкций по техническому взаимодействию).
- В область дата-аналитика (сделай отчёт по экселю).
и ещё в десяток.
Думаю, в небольших российских компаниях также нет чётких границ между разными должностями/ролями. А значит, к аналитику будут предъявляться специфические требования "сделай то, чем никогда не занимался раньше".
В больших такое тоже вполне бывает. Просто потому, что в больших компаниях тоже бывают маленькие и средние команды, где иметь отдельного бизнес- и отдельного системного аналитика — непозволительная роскошь. Одному из них просто нечего делать будет большую часть времени.
И да, они обычно еще и тестируют же…
Спасибо. Интересно было почитать.
Скажите, а что для Вас больше важнее? Умение смотреть на ситуацию сверху, формулировать определения, обладание хорошей памятью или знание инструментов/технологий?
Инструменты и технологии - дело наживное, тем более для СА. От Senior я бы ждал наличия какого-то набора инструментария, который является "продолжением руки". Причем не так важно какого именно - просто как подтверждение наличия опыта и "ремесла в руках". От других уровней - не так важно.
"Хорошая память" вообще не критерий, скорее "наличие навыка работы с информацией".
"Умение смотреть на ситуацию сверху", "формулировать определения" - это всё про одно и то же, про уровень мышления.
Это ближе к навязыванию своего видения, а то и образа жизни, чем собеседованию. В просторечии меряние кое-чем. Речь идет о людях даже не на развилке пути, а в самом его начале. Вкладываться в то, что через год-другой станет не актуально? Умению отфильтровывать ненужную по жизни информацию у зумеров можно поучиться.
Красноречие это индивидуальная особенность, как склонность к рисованию или музицированию. Сформулировать осмысленное определение чего-то сходу, лицом к лицу, не каждый СА сможет. На бумаге, спокойно подумав, каждый. Опытные гуманитарии, писатели да журналисты, и те часто избегают словесной полемики в пользу переписки, если перед ними более сильный противник, с лучше "подвешенным языком".
Про то, что все эти вопросы на "кругозор" (проще, на "придурковатость") с переносом гор и смешиванием ложечкой жидкостей из разных емкостей никак не показывают уровень человека, как то Гугловский главный кадровик писал. У СА может быть "другая" жизнь вне работы с 9 до 18. С тюнингом машины в гараже, игрой в ночной хоккейной лиге, и тому подобным. Самый лучший СА в моей практике был увлеченным рыбаком.
"Это куда это вы собрались расти?" - как то осадила кандидата простоватого вида кадровичка. Девица может и была туповата, да сказала она неудобную правду: гарантировать карьерное развитие сотрудника ни одна компания не может. И излишне амбициозный человек через год-полтора сбежит. Сообразительный кандидат от ответа на этот вопрос просто уклонится.
Вот так выглядит старческое брюзжание.
Вот так выглядит старческое брюзжание.
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
При проведении собеседований в те годы (как раз в 2012 году был первый опыт в роли интервьюера на позицию аналитика) упор был на техническую составляющую: на собесе составляли требования, рисовали различные диаграммы, прототипы и т.д.
С возрастом шкала оценки меняется - сейчас по технике спрашиваю буквально пару кейсов. Основная часть беседы - проверка способности к самостоятельному мышлению.
Так что да, это в том числе и старческое брюзжание. Сократ на обложке это подчеркивает.
Не стал бы я во всём следовать Сократу...
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
Может быть тогда на них все могли ответить? Спрашиваете же вы реально просто базу, которой должен владеть "человек с хорошим университетским образованием". При это реально образование может быть любым естественно-научным: физик, биолог, математик, энергетик.
Короткая память — это широко известная проблема клипового мышления, про которую ещё когда писал Кара-Мурза в "Манипуляции сознанием".
Как аналитик, я бы подумал что у интервьювера, как минимум не все в порядке в компании, раз он задает вопросы не имеющие практического подтекста.
Вся эта теоритическая чушь, распадается о реалии жизни, и вылетает из головы за ненадобностью в первый год.
Вигерс, бабок, и тд. Это хорошо, но у тебя горят сроки и нужно скорее требования написать, так как поймет команда и одобрит заказчик.
Mysql, oracle, да все равно на это аналитику.
Возьмём, к примеру, абсолютно серьёзную отрасль real estate. Системный аналитик может быть востребован здесь в службах провайдера телекоммуникаций, но при условии полной инженеризации личности (пространство профдеформации). Не для всех, способных к этому, скромная компенсация в два с половиной килодоллара является достаточной. Поэтому капитализм всячески подавляет юнитов для сговорчивости, автоматически проводя каждого через принудительную безработицу.
Если человек не хочет учиться, у него могут быть довольно веские основания – нейронные связи не резиновые. Античный раб-учитель этого не способен осознать, а про советских инженеров позабыли далеко не все из молодых.
Это не повод стараться изменить рынок труда, разумеется.
Хотелось бы для чистоты эксперимента увидеть описание вакансии и требований к кандидату.
Иметь много инструментов в ящике – это хорошо. Уметь пользовать каждым из них – прекрасно. Но не менее важно понимать границы применимости и в каждой конкретной ситуации использовать наиболее подходящий инструмент – чтобы не забивать молотком шурупы.
Странное требование от аналитика. Аналитик же чаще всего не занимается выбором инструмента, он использует то, что уже внедрено. И если он действительно на позапрошлом пользовался внедренной постгресом и научился им хорошо пользоваться, а на прошлом - пользовался внедренным ораклом и научился им хорошо пользоваться, то почему из этого следует вывод, что он должен уметь выбрать из этих двух более подходящий инструмент?
Кажется если что и можно спрашивать здесь - так это "чем было комфортней пользоваться", "в каком из инструментов было проще решать типовые\нетиповые задачи" и т.д., т.е. просить сравнить именно опыт использования.
СУБД здесь не лучший пример.
Лично имел дело с одним человеком, который знал только BPMN и использовал его для всего. И диаграммы состояний, и диаграммы взаимодействия, и потоки данных, и алгоритмы - все рисовал на BPMN. Понятно что часто стандарту это не всегда соответствовало, но понять было можно (приложил определенные когнитивные усилия).
Если бы в "ящике с инструментами" было больше нотаций - можно было бы под каждый случай выбирать наиболее подходящую. Это и более общепринято, и рисовать проще, и понимать легче. Но поскольку в ящике лежит только BPMN - имеем то что имеем.
Не, если говорить про область ответственности аналитика, там где он выбирает и внедряет и сопровождает решения (нотации, форматы и процессы управления документацией, процессы сбора и формализации требований и тд), то да, тезис вполне актуальный.
Просто на СУБД совсем неуместно смотрится пример и вызывает отторжение. Предложу поменять в статье )
Вот покажите мне неаналитика, который IDEF0 поймет.
BPMN (а точнее "по мотивам", упрощенный) — лучший и практически единственный инструмент общения с заказчиком. Все понимают кто, что и в каком порядке делает, даже если ничего не знают про нотацию.
Когда пытаются использовать нотацию для общения с людьми в полном объеме — снова начинается тупняк на отличить разделение в параллель от выбора ветки и тд.
Упрощенный датафлоу хорош, когда не надо думать об исполнителях, но этого почти никогда не бывает.
Приветствую автора. Наверное не каждый интервьюируемый вникал в познавательные процессы или когнитивную психологию. Всем советую, прочитайте "Критика чистого разума". Много нового узнаете, будете на интервью "блестать" :)
Канта я пробовал читать, но его честно не осилил
Очень тяжело идет :(
В школе идёт урок труда у девочек 5-го класса. Учительница начинает:
Сегодня у нас непростая тема: "Выворачивание канта наизнанку". Тут одна из учениц тянет руку.
Ну что такое, Сидорова? Опять у тебя какой-то вопрос?
Да, Мариванна. Это что же такое получается: нравственный закон над головой, а звёздное небо внутри нас?
А нужны ли такие аналитики, каких ищет автор? Зачем они в современном мире? Неужели есть где-то контора, которой реально полезны глубокий анализ и системный подход?
Мне жаль автора. Он ищет умных людей. А фирме нужны сговорчивые исполнители. Автор об этом подозревает, но либо в конторе бардак и ему позволено вольничать, либо выше кто-то из таких же, но во втором случае работает бардак уже на его уровне. Третьего не дано. К сожалению.
Поэтому в среднем по данной больнице наблюдаем вопль возмущения в комментариях - как, я же умный, я всегда отвечал как автору не нравится и всегда имел хорошую з/п, а он тут меня окунает лицом в нечистоты! Ладно, не так жёстко, но в целом имеем именно возмущение и возражения по той же причине.
Было бы интересно понять, на сколько далёк автор от понимания реальности. Варианты следующие:
Не ведает
Что-то подозревает
Понимает основы, но не видит общей картины
Я вообще за разумных коллег, но реальность такова, что разум конторам обычно не нужен. Даже если они пишут обратное в требованиях к вакансии. Уж не на эти ли требования повёлся автор?
Если не проверить наличие "глубокого анализа" (ну ладно, не глубокого, хотя бы какого-нибудь) и "системного подхода", то есть высокая вероятность набрать таких исполнителей, глядя на результаты работы которых хватаешься за голову и спрашиваешь - "ЗАЧЕМ ты это сделал?"
Не "ЧТО", а именно "ЗАЧЕМ". Потому что сделано может быть быстро, аккуратно и технически грамотно - к этому не придраться. А вот с целеполаганием и соответствием окружающей действительности - просто беда.
Вот для этого нужен разум.
Вы строите локальный мир, удобный для вас. Вы это понимаете?.
Вопрос "зачем" важен для акционеров конторы. Вы выступаете в роли доброго малого, помогающего акционерам жить вольготно. Да, вам за это платят, и это в некотором смысле оправдание для вас. Но тем, кто выше вас по должности, платят во много раз больше, и именно они во множестве случаев игнорируют проблемы в ТЗ, про которые вы пишете "зачем ты это сделал". Даже не просто игнорируют, они генерируют входящие требования, которые уже послушно записывает и как-то оформляет очередной аналитик. Вы исправляете их ошибки.
Но бардак вокруг умных людей убивает психологически, поэтому они вынуждены исправлять ошибки, текущие бурным потоком сверху. Рационально? Глобально - нет. Но на локальном уровне "задача получить максимум из имеющейся ситуации" вы как-то справляетесь.
Как аналитик вы должны понимать разницу в эффективности между локальной оптимизацией и глобальной. Как умный человек вы должны понимать глупость ситуации, в которой все вокруг заняты исключительно локальной оптимизацией. Ну а как рационально действующий (в очень узких рамках доступного) субъект, вы обязаны оптимизировать своё окружение под себя, чем помогаете локально оптимизировать выгоды всем выше стоящим, то есть ещё сильнее отдаляете идеал в виде глобальной оптимизации.
Вас радует жизнь такой шестерёнки в чужом механизме?
Хотя да, деньги позволяют забыться. Плюс жена, дети, ипотека. Ну и вечный бардак вокруг. Если не думать, то сразу становится легко. И те кандидаты, которых вы отсеяли, по части "не думать" гораздо лучше вас локально оптимизировали свою жизнь. Они счастливее вас. Задевает ли умного человека такое положение? Или он увлёкся теоремами Вейерштрасса и обо всём остальном забыл?
Ладно, не буду зудеть. Но было бы неплохо глобально оптимизировать этот мир.
Но было бы неплохо глобально оптимизировать этот мир.
А это неизбежно — у текущего зазеркалья есть предел жизни, определяемый воспроизводством общества. Но, скорее всего, всё долбанётся ещё раньше.
Что неизбежно? Вы затронули сложную тему, но ответ получился крайне поверхностным.
Здесь не место неповерхностным ответам, т.к. они зыбки, неизбежно частично ошибочны, а поэтому требуют доброжелательной атмосферы для обсуждения. Невозможно, заниматься нормальной научной работой в высококонкурентной среде — вас съедят. Так и тут.
А где место? Мне интересна тема, было бы полезно обсудить. Могу в личку написать, или предложите форум какой-нибудь. Но лучше здесь ответить, а на недоброжелателей болт забить.
Невозможно, заниматься нормальной научной работой в высококонкурентной среде — вас съедят.
А как же работу ведут во всяких Стенфордах с Йелями, если везде сплошь publish or perish и битва за гранты с тенюром любой ценой?
Плохо ведут. Биотехнологии, как вы заметили, не взлетели, в отличие от той же микроэлектроники. В физике плазмы прорывы у китайцев (возможно те как-то уменьшили publish-or-perish).
В частности из-за того, что из-за publish-or-perish в научных работах примерно 50% невоспроизводящихся результатов (это значит, что вы должны опираться не на 2 экспериментальные статьи, а на десяток).
--------------------------------
Чудес, понимаете, не бывает — если у вас высококонкурентная среда, эффективнее заниматься написанием доносов грантов, мрий и плохо проверенных статей, чем качественными работами (которые связаны с самокритикой).
Как только вы сказали "должна же быть хоть какая-то метрика КПИ" вы проиграли. Неужели вы всерьёз думаете, что люди, взламывающие законы природы не смогут расколоть какой-то несчастный КПИ?
Даже с программистами такое не работает (см. пресловутые "строки кода"). А тут — люди, профессионально изучающие неизвестные законы природы и ставящие их обществу на пользу. Только порядочность, честь цеха, идеалистичность, ответственность не дают сразу эти несчастные хирши ломать сразу.
Несчастные китайцы, у которых этого научного цеха не было, бросились ломать систему KPI. В результате, им пришлось идти на поклон к западным рецензентам, иначе вся китайская наука сразу схлопывалась.
Понимаете, я набираю слепым десятипальцевым методом примерно страницу в час. А нормальная статья из 7 страниц делается треть года или больше.
Я пессимистичен — пока Реставрация не закончится (ещё лет 20), ничего реально прорывного не будет.
Но хотя бы уменьшить давление publish-or-perish. Неплохо бы получить целевые заказы на исследование от промышленности.
Я пессимистичен — пока Реставрация не закончится (ещё лет 20), ничего реально прорывного не будетМожно поподробнее про современную Реставрацию (я без подкола)?
Но хотя бы уменьшить давление publish-or-perishЗвучит красиво, но как?
Неплохо бы получить целевые заказы на исследование от промышленности.Промышленности нужная инженерия, фундаментальная наука сразу загнется. Если же говорить о гос-промышленности, то это будет Сколково-2. Как определить кто достоин финансирования? В современных реалиях.
Можно поподробнее про современную Реставрацию (я без подкола)?
Посмотрите на историю французских буржуазных революций, там качели "революция-реставрация".
Аналогично и с социализмом: у нас идут периоды Революций-Реставраций. В зависимости от того, рассматриваете ли вы Парижскую коммуну, как первую соц. революцию, сейчас либо первая, либо вторая капиталистическая Реставрация.
Почему она конечна? Ну, если у вас есть дети, то вам очевидно, что социализм нужен просто для воспроизводства индустриального общества. Собственно, на этом стоит тот же Хакслиевский "Brave New World" (там коньюнктуры для есть очевидные идиотизмы — дураков не надо специально делать, они сами родятся).
Всё очень просто: вам нужны миллионы образованных работников, значит вы должны им дать три кита: образование, жильё, медицина.
Причём если вы выдадите деньгами, то идиоты обязательно купят айфоны вместо хорошего образования детям. Следовательно (по ТРИЗ) это надо дать бесплатно. Аналогично с жильём и медициной.
Соответственно, социализм неизбежен => будет конец Реставрации. Когда? Да вот уже, с 24 февраля началась активная фаза, а некоторые отсчитывают с 2013 года, когда РФ захотела делать БРИКС.
Но поскольку мир сильно больше Франции, из общих соображений все эти качели имеют больший период. Поэтому всё идёт так неспешно.
> Звучит красиво, но как?
См. выше, можно просто подождать.
> Как определить кто достоин финансирования? В современных реалиях.
Это бессмысленный вопрос в капиталистическом государстве. Тем более, задаваемый людьми, которые ничего не решают.
Плевать на воспроизводство.
Даже в Японии, с её уже десятилетиями стареющим обществом, все еще есть бесполезные работы ради работы. Т.е. пока кто-то там повышает автоматизацию японского производства, кто-то стоит на светофоре и считает людей.
Даже в России есть миллионы условно-нужных-но-ненужных людей.
Мелкие бюрократы, которые плодятся в условиях размножающихся справок.
Охранники. В каждой пятерочке есть молодой детина, который там особо не нужен. Тревожная кнопка - нужна, а садить в каждую пятерку по взрослому мужику?
Но и ВОХРовцев (только при росгвардии) еще 100 тысяч человек. А еще сколько частных на кнопке и в экипажах?
Вахтёры.
Охранников и вахтёров - 2 миллиона людей! При том, что у нас скоро камер будет больше чем людей. Вы скажете - камера-камерой, но как она пропустит человека? Да как домофон. Нажал на кнопку, сказал куда и зачем, показал себя и любой документ при себе, тебя пропустили (или не пропустили). Один "оператор" сможет заменить десяток вахтёров.
Миллионы людей, которые заняты херней. И есть еще миллионы людей, которые официально ничем не заняты.
Реально общество сможет жить до тех пор, пока есть кому работать в агросекторе (и я тут про птицефабрики и фермы, а не про личное подсобное хозяйство на деревне) - это 5% трудоустроенных, производстве - это еще 10% трудоустроенных, и всякие там услуги водоканалов и транспортов - это еще 10% трудоустроенных.
Остальные, в общем случае, делают какую-то работу, но без которой страна не развалится, не умрёт с голоду, и даже будет одета-обута и в тепле.
Хорошо сказано!
да, работать надо с тем что есть, это данность, ждать розовых единорогов утопия
Спасибо за статью - есть полезные лайфхаки. Например, вопрос про сравнение двух похожих инструментов при наличии их в резюме.
серьезно, чуть ниже мидла, и 200к ??
Московские расценки за чувака в офис. Да. Без удаленок, гибридов и прочих Бали или хотя бы Сочей.
Потому что даже из Сочи 'на какое-то время' звучит как некий банк, в котором удалёнка ограничена регионом офиса, а на удаленку в Сочи тебе даётся 90 дней в году.
Так себе такая удалёнка. Удалёнка - это когда ты работаешь там, где хочешь, а не там и так, как решил твой работодатель.
На вопросы о том, что было пару лет назад, кандидаты часто отвечают «это было давно, не помню уже»
Если меня спросят чем я занимался на работе 2 месяца назад - я сильно задумаюсь, потому что все с годами воспринимается как однообразная рутина.
Жиза, причем похожие ощущения от некоторых претендентов на сеньорство
В данный момент тоже в поисках системного аналитика, но за денежку больше чем у автора.
Ищу именно системного, а не ба + си.
Пока все валятся на шаге задания:
Дается некая вводная от бизнеса(новая фича). Нужно на основе этой вводной
сделать постановки для разработчика.
Условия задания - у разработчика уровня мидл, не должно возникать вопросов по представленной постановки)
Автор дал конечно) про то, что ищет 2в1 по минимальному прайсу я всё-таки упомяну
вот интересно следующее с чем сталкивался: хотят чтобы разбирался в отличиях инструментов, хотят чтобы был начитан, хотят чтобы много чего умел
а в итоге я сижу и клепаю отчёты для руководства, попутно занимаясь какой то хернёй... на мои пассажи о том, что дайте мне студента или секретаря (пол не важен) я его этому обучу, т.к. не моего уровня задачи, и уже отпУстите меня или дадите другие, более релевантные задачи, мне отвечают что-то в духе "ну что ты, это же аналитическая работа для аналитика". Зачастую в компаниях предлагают дружный коллектив, работу в компании-лидере отрасли (при том каждая 1 такая компания-лидер). Хотят много чего, по этому это много чего и пишут в резюме, а что делать?
Про то, кем вы видите себя через 5 лет(я здесь и далее нарочно переврал формулировку)... ну да, у нас же в рфии горизонт планирования именно такой, а то и больше, чтобы я спокойно мог сказать что я буду изучать, куда стремиться и прочее (именно по этому за неделю у меня случилось чемодан, вокзал, имя страны и теперь я безработный бомж)... у меня же нет жизни кроме работы (допустим что она есть, и я не сижу в прострации после рабочего дня по 3-4 часа и не смотрю в точку в мониторе дома и не думаю как найти в себе силы, чтобы приготовить что-то поесть, т.к. последний раз ел на работе и не ненавижу себя и всё вокруг) и развития себя в ней. Обычно изучение чего-то нового сопряжено с тем, что ты с новым столкнулся
Этот тест про формулирование мыслей... тут несколько сложнее, я исхожу из того, что мне работать с разработчиком, я какое то время ищу подход к человеку и стараюсь предрасположить его к себе, будь то в рабочих моментах или в нерабочих, вырабатываю эмпатию.. а дальше я могу ему хоть в танце как у пчёлок объяснить что я от него хочу. Мне главное чтобы он меня понял, а потом хоть как то это зафиксировать на бумаге для будущих поколений (история про остров, швабры и 200 тонный вентилятор ну хотя бы стикеры должны быть наклеены). Зачастую всякие ЮМЛ используются как придётся, чтобы донести до человека и все поняли, т.к. не все владеют (и я тоже) в полной мере этим инструментов, а он очень нагляден и удобен. Я в своём подходе, естественно, могу быть не прав и надо чётко только на бумаге, до запятой, без личного общения и вот это вот всё.
Хотел еще понаписать, но я не хочу ни в коем случае громить автора или выставлять себя дураком, т.к. найдутся более компетентные кто скажет что и я не прав, просто мнение с другой стороны, нежели автор. Не принижаю точку зрения автора, не знаю что творится с кандидатами, т.к. себя считаю не очень удачным представителем стороны кандидатов на вакансию и для меня всегда дичайший стресс подобные интервью, но видимо у автора, как представителя компании бомбит так же, как у меня на представителя компании :) без негатива
так миллениалы же, что вы от них хотите. Они ещё ничего, вот пойдут зумеры тогда наплачетесь
Дисклеймер: я хочу автору позадавать вопросы для более полной синхронизации с его месседжем. И, возможно. навести на новые мысли.
Автор, правильно ли я вас понял, что:
Вы делитесь своими субъективными переживаниями от собеседования кучи "специалистов" с неоправданно завышенными зарплатными ожиданиями? То бишь вам пригорело по итогу икс собеседований за период.
Вы старательно ищете на рынке кадры, которые вам будут идейно близки (задротство в терминах, а также четкое знание матчасти).
Правда мне не очень понятно как это поможет выполняемой функции системных аналитиков? А какая она основная функция системных аналитиков, кстати. Ну, по вашему мнению? Что является результатом работы аналитика? Без воды, желательно. Задача: описать результат работы аналитика в 2 предложениях.
Пояснение: я хочу понять каким образом четкое знание матчасти и терминов вяжется с ожиданиями результатов работы конкретного кадра. Например, если я ищу повара - меня интересуют какие блюда он умеет готовить и как быстро и качественно он это делает. А чтобы понять правду он говорит или нет - я дам ему задание приготовить одно из названных блюд. И оценю время, качество и вкус. А ещё посмотрю на подачу, состояние кухни после готовки и ошметки от ингредиентов. Надо ли при этом повару знать чем помидор отличается от свеклы и как их выращивают - вопрос. Это может быть точкой роста на перспективу по мере наработки статистики по продуктам.
Вы хотите немного почесать своё ЧСВ (своим опытом). Я тут без наезда. Это просто пирамида Маслоу - жажда признания (профессионализма).
"Делюсь субъективными переживаниями" - совершенно верно, только личный опыт и никаких претензий на объективность. Насчет "завышенных зарплатных ожиданий" - на этом не акцентировался, не готов судить какой уровень зарплаты адекватный, а какой завышенный. Возможно где-то в другом месте нужен кандидат именно с этими навыками и его оторвут с руками. "Пригорело" - нет, ничего не пригорало, скорее удивление и легкое разочарование.
Я ищу на рынке кадры, которые эффективны в конкретных условиях. Что такое "эффективны" - тема для отдельной статьи, там много аспектов.
Функция системного аналитика - разработка и сопровождение требований к программному обеспечению. В профстандарте "Системный аналитик" нормально написано про это.
Да
я хочу понять каким образом четкое знание матчасти и терминов вяжется с ожиданиями результатов работы конкретного кадра
Там в основном про создание и работу с формализованными определениями. Это же базовый навык для "цели жизни" аналитика — упорядочения хаоса. Какой сумбур вместо музыки напишет аналитик, который не понимает, как делаются определения, не умеет выделять главное, отсекать ненужное?
Услышав первый затянутый ответ, я переспрашиваю «Правильно ли я вас
понял, что…» и повторяю ключевые мысли из ответа кандидата, но раз в
десять короче и более структурированно – например, в формате
нумерованного списка (во-первых, во-вторых, в третьих).
Это может быть как манипуляцией со стороны кандидата (не всегда осознанной - типа "вдруг 1 высказывание из 100 будет верным") так и собеседующего.
Как правило на собеседовании вариант: "я 5 минут подумаю, потом сформулирую 30-секундный ответ" не подходит. Но вот то 5-минутное говорение - оно часто является необходимым этапом для переформулировки знаний из формата "знает как сделать" в формат "знает как изложить для другого".
Но вообще, частенько на совещаниях приходится «выслушать коллегу, и — для занесения в протокол — повторить его ключевые мысли в виде краткого нумерованного списка». иногда нумерованный список оказывается из одного пункта, и в три-четыре слова.
Уж кому тут действительно нужно системное мышление, так это автору этого безобразия. Становится очередным примером того "каким не нужно быть" незавидная судьба даже такого бездаря. Скучаешь по родной кафедре, бедняга, но это даёт тебе никакого права изводить свою скуку на других.
Не соглашусь с большинством комментаторов. Статья весьма познавательная и даже в чём-то полезная. Однако и с автором тоже соглашусь не во всём.
Начинается новый проект, нужно автоматизировать бизнес-процесс, который сейчас выполняется «на бумаге»
Сразу вопрос: кому? Соответственно, плясать нужно от него. Пообщаться с ним, узнать его мнение и задать второй вопрос: зачем? После этого можно или согласиться, или обоснованно не согласиться с доводами - и пойти к тому, кто может это обеспечить (начальник). А затем - к тем, кому с этим е работать.
2. Озвучивание предыдущего опыта без каких-либо обобщений: «технологию А я использовал на прошлом месте работы с такой-то целью, а технологию В на позапрошлой с такой-то целью»
Эм, ну вообще это наиболее разумный способ дать ответ на поставленный вопрос или хотя бы подойти к ответу. Продолжая вашу аналогию - если мы спросим, чем определяется применение молотка и отвёртки, мастер в первую очередь будет руководствоваться собственным опытом, а уже потом - какими-то теоретическими соображениями о сопромате, коррозии и экономической эффективности. Вам следует, используя такой ответ на вопрос, предложить соискателю развить его, проанализировав, почему он выбрал ту или иную технологию в конкретном случае.
По первому пункту - вы даёте просто отличный ответ на кейс. К сожалению такого ответа от кандидатов я не получаю.
По второму - ну вот вам пример, про область применения ложки и вилки. Кандидат озвучивает прошлый опыт: ложкой я ел грибной суп и манную кашу, а вилкой - спагетти. Это прекрасно, но для нормального ответа на вопрос стоит дать обобщение - что ложка нужна для жидкой пищи, а вилка - для твёрдой. Без обобщения ответ слабый.
У меня вопросы к системе «аналитиков».
Зачем человеку, чья задача перевести алгоритм с языка кулинарных рецептов на математический язык компетенции в кодерских программах и даже дизайнерских? Он не будет кодить, ему стоит быть математиком и читать Дейкстру. Может быть, из-за того что в требованиях к вакансии только технологии набора кода, и не попадаются люди готовые поговорить о топологии?
Очень странный кейс: вы пошли к начальнику, руководству на местах и сотрудникам спросить что нужно делать… Это не аналитика задача, а специалиста по системе менеджмента. На производствах, в научных центрах, на каруселях, в ресторанах, заправках, короче, везде кроме как тупо в офисе - система менеджмента регулируется нормативкой и даже федеральными законами. Не важно что хочет начальник, должно быть то что хочет государство. При этом сама нормативка, например стандарты серии ISO9000 - сборник загадок Жака Фреско. Человек умеющий рисовать прямоугольники в figma никогда не сможет догадаться как реализовать систему менеджмента по нормативным требованиям. Так что ответ на этот вопрос должен быть: нужно пойти к СМК-шинку, а если его нет и система менеджмента не установлена - обратиться к специалисту, знающему все регуляторные документы в этой области и с опытом защиты этих знаний перед гос органами.
Если предполагается что аналитик сам должен построить систему менеджмента, может стоит тогда набирать людей с компетенцией в менеджменте качества, рисков и процессов? Для них есть даже аттестационные центры. Можно получить человека, который будет доставать корку аудитора СМК и томным голосом говорить: «покажи мне свою верификацию!»
А где, собственно, ваши ответы на каждый упоминаемый вопрос? Я не увидел. Возможно, где-то в тексте есть. Вероятно, ответы вызовут обсуждение, которое будет полезным.
Почему бы не писать в формате:
Вопрос:
Рассуждения:
Ответ:
Вы же используете только вопросы и негодование.
Известная история из серии - найдите мне ведущего специалиста возрастом до 25 с опытом работы от 10 лет в компаниях из первой десятки...
я начал с вопроса о значимости первой теоремы Вейерштрасса
А можно узнать, что хотелось услышать в ответ на этот вопрос? Ну, кроме того, что много других вещей из "базового" анализа так или иначе ее используют в качестве какого-то из шагов доказательства (кажется, из нее сразу следует, что непрерывная функция принимает все промежуточные значения, итд итп)
Видимо, я тоже плохо знаю анализ.
Извините за то, что задал вопрос не по основной теме.
Пример статьи автора, про гламур и дискурс в стиле Пелевина. У меня извращенное видение всей картины так сказать по другую сторону зеркала. В тестирования я пришел, вляпался когда имел за плечами опыт администрирования высоконагруженных корпаративных систем. Есть стойкое понимание где требования не учтены, тестеры болта клали, а этот "юзерфрендли" интерфей не вызовет приступ тошноты у человека со зрением -7.
Оттурбив в тестировании более трех лет, отмучав более 11 команд программистов, могу сказать что самое важное не только "Требования к продукту" а логический анализ, его к сожалению разучились делать. С программистами и их "не хочу", "не буду", "не умею" - порядок навели, а вот четкого понимания зачем мы идем от точки А к точке Б, у продактов/аналитиков, каких мать в пень "ДЖУНОВ", там бьют себя кулаком в грудь да "Я СЕНЬОР" нет как класс.
И воронку нарисуют, и опрос проведут. Мы реализовали дорогу из точки в а в точку б за пачку денег, что ты мил человек получил? Какую цель достиг пользователь. Пользователь перед дверью, дальше что? Аналитик смотрит на тебя глазами светлыми и наивными: "и ответ пользователь откроет дверь".
Ты ему: ДА ЛАДНО? Дверь согласно ТЗ не открывается, ручки нет, более того за ней стена! Потому, что кто-то описал маршурут в БАШКЕ не оставил места для просто понимания что процесс или действие должно к чему-то проводить.
Мычание аналитика: А что делать?! Даю 3 минут на устное изложение что ты хотел! Не 5 ни 10 минут РОВНО 3. Штаны снимать поздно, обосрался стой рассказывай. Деньги списаны в концепции тайм энд матириал и этим вот результатом мне надо как тестировщику что-то делать.
Потому что релиз не завтра, но дедлайн видео и набор функций который пойдет на рынок надо структурировать и дать пользователю в простом и доходчивом виде. Не все то ТОПЧИК что в фигме нарисовано.
"Что-то делать" кратко и образно сохраняя политес не собирать скальпы программистов их аналитика который задание ставил, аналитика который составлял тз, сочинять окно в которое поместится пользователь что бы ознакомиться с функционалом который замыслил но не домыслил продакт.
Речь о том, что когда интервью строится люди должны говорить на одном языке, можно матерном, и оба понимать какой маршут и для достижения каких целей выбран.
Всем терпения, пошел возвращаться к своим командам программистов, прошу прощения за длинный и несуразный опус. жизненно.
Поясните, пожалуйста, зачем сис/биз аналитику знать разницу между субд? Это проблемы архитектора, разве нет? Про бизнес аналитиков знаю, кто такие системные не особо. Они могут предлагать варианты реализации? От бизнес аналитика мы получаем результат "бизнесс процессы должны быть вот такие", что выдает системный? По статье хотел сказать: экономику знать надо ещё и предметную область, это самое важное имхо, после опыта конечно. В книжках все это хорошо и красиво, на практике все в стиле "впихнуть невпихиваемое".
Нигде не было утверждения что аналитику надо знать разницу между СУБД. С моей точки зрения это не требуется.
Но если кандидат указывает в резюме в разделе "Ключевые (!) навыки" две СУБД, то логично ожидать что он про них что то знает. А если знает - то может сравнить.
Проблема не в том что не знают разницу между СУБД, а в том что в резюме пишут ерунду и потом не могут подтвердить написанное.
Мне кажется, проблема автора в том, что он собеседует системных аналитиков" уровня junior/middle", а вопрос задает как разработчику или, скорее, солюшен архитекту. Понятно, что в резюме могут написать много ерунды, которую надо на 2 и на 3 поделить, но тем не менее.
В подавляющем большинстве случаев бизнес или системный аналитик будет работать с тем стеком который уже сложился. А на новом проекте технологии будут определять другие люди. И даже если у аналитика "с 1-3 годами опыта" будет реальное понимание чем Postgres отличается от Oracle, к его мнению может быть кто-то прислушается но не более.
Я бы выделил такие качества для junior/middle аналитиков - способность быстро обучаться и адаптироваться к новым проектам и технологиям. Умение коммуницировать со стейкхолдерами и инжиниринг командой, принимать верные решения и оценивать риски.
Если делить одну из теорем Вейерштрасса на 1 и 2 (так действительно делают) - то первая будет о том, что непрерывная функция, таки ограничена на компакте. О том, что она достигает максимума и минимума на этом компакте - это уже вторая теорема. Но, вопрос о значимости меня так же ставит в тупик. Ну и вопрос о том, почему люки круглые... простите, об отличиях REST и SOAP - зачем сравнивать архитектурный стиль и протокол? Ну спросите чем SOAP отличается от XML-RPC, если нет более важных вопросов на собеседовании
об отличиях REST и SOAP - зачем сравнивать архитектурный стиль и протокол
К сожалению кандидаты в большинстве своём не знают что REST это архитектурный стиль. Более того, я не уверен что они знают чем "архитектурный стиль" отличается от "протокола". Для них REST и SOAP - одного поля ягоды.
Поэтому вопрос принимается как естественный и имеющий смысл, и они пытаются отвечать по мере своего разумения.
Вопрос без условий, что лучше оракл и постгри, в вакууме, алогичен вопросу что лучше анал и орал случайно выбраному хуману ) Нужны начальные условия, хотя бы ориенетация компании ) И для чего это будет использовано.
Сколько junior вы нашли с такими критериями?
Читая вашу статью, я вижу требования к senior и начальный уровень архитектора, я в профессии более 8 лет и успела увидеть несколько компаний и проектов, начинала как раз с junior позиции.
Определения - это хорошо, но аналитик это не википедия, которая сыпет в разработчика определениями. Главное для junior (моё мнение) - это умение думать здраво, слышать и горящие глаза с желанием научиться. А если человек ещё и позитивные, это прям повезло.
Конечно, он должен иметь знания по hards скилам, но без того, что написала выше, работать вряд ли сможет.
Ещё момент про книжки, где вы берете время, чтобы их читать? На работе ставят задачи и у них нет времент, чтобы вы читали книги, им нужны решения, поэтому я благодарна habr, интенсив курсам, митапам и конференциям, где люди делятся знаниями в сжатом виде, потому что мозг аналитика в режиме многозадачности книг и определений просто не поместит.
Сколько junior вы нашли с такими критериями?
Мхм, я где-то писал что ищу специалистов уровня Junior? Попадались и вполне нормальные ребята, которых чуток подтянуть - и полноценная боевая единица готова. Джунам разумеется надо задавать совсем другие вопросы.
Поиск прошел нормально, доля собеседований которые закончились оффером близка к моей средней.
Читая вашу статью, я вижу требования к senior и начальный уровень архитектора
Это очень интересно, потому что в статье нет вообще никаких требований :) Где вы их там нашли?
Ещё момент про книжки, где вы берете время, чтобы их читать?
Есть у меня такая дурацкая привычка - читать. Примерно час-полтора в день получается. Понятно что это не только профессиональная литература, но и она тоже.
Я считаю, что middle - это 3+ лет, а senior 5+, значит всё что до, это как правило junior. Почему так? За это время как правило у аналитика появляются различные задачи и он уже может и сверху посмотреть на задачу и провести сравнительный анализ технологий на минимальном уровне.
Про требования. Вы пишите, что хотели бы слышать на собеседовании, а это косвенно требования, потому что ответы показывают уровень знаний кандидата.
Рада, что вам попались кандидаты, как вы искали. Я считаю, что у молодёжи сейчас есть другие плюсы, кроме как знать определения. Я встречала не молодежь, которая не знает определений и работает уже на уровне главных специалистов, но они прекрасно выполняют задачи и являются хорошими боевыми единицами.
Я вам завидую, что находите время читать именно книги, это здорово!
👍 спасибо за статью, здорово, что тема актуально и затронула много читателей.
Если что-то заявлено в «ключевых навыках», то я ожидаю от кандидата возможности вести содержательный диалог на эту тему. А по факту объем заявленных в резюме навыков нужно делить на 2, а то и на 3.
"Не мы такие, жизнь такая". Когда в 100500 вакансиях видишь портянку из баззвордов и понимаешь, что туда вписали все, что в голову оформителю и(или) составителю текста пришло + коллеги по цеху с полуострова Индостан, у которых резюме толщиной не с Махабхарату - не резюме, а недоразумение, то начинаешь проявлять адаптивное поведение и затацивать резюме под вакансию.
Штош... Ну удачи вам найти хоть кого-то. Хотя бы через год-два. Потому что либо кандидат должен согласиться на меньшую зарплату либо это должен быть какой-то "гений", который не читая книги сможет конструктивно ответить на каждый вопрос. Только вряд ли такой попадётся.
А я в какой-то степени понимаю боль собеседущего.
Если у тебя в резюме указано что ты знаешь A и B, но не можешь сказать каких-то ключевых характеристик, то этоточно говорит о том, что человек их не знает.
одно дело спрашивать какой хедер надо указать чтобы передать xml.
но если указан SOAP и REST, то он как минимум должен это знать, если гражданин знает матан (я его например не знаю, ну т.е. пределы, интегралы и прочее это понятно), то базовые вещи, пределы и теоремы он знать должен иначе это вранье, либо рассказать в каком объеме знает.
Автор абсолютно правильно спрашивает про рассуждение, потому что все IT это постоянное принятие решений и для чего тебе м***ак решение которого надо контролировать постоянно?
Который мог просто банально понатаскаться на типичные вопросы, а думать не умеет.
То же самое и с программированием, типовые задачи, типовые вопрсоы, а на выходе г-но. Потому что проблемы это всегда задачи с каким-то тонкостями и надо правильно выработать или выбрать решение.
Это не хорошо и не плохо, это обычная ситуация на рынке труда, одни хотят «купить» себе работника подешевле, а потенциальные работники хотят «продать» себя подороже.
Дискуссия в комментариях в основном идёт на следующие темы:
Конструктивная дискуссия по теме статьи. По мере сил своих в этом участвую.
Чем отличается Oracle от PostgreSQL. К статье никакого отношения не имеет, но почему бы про это не поговорить.
У автора (или в компании автора) проблемы и он все делает не так.
Требования к вакансии имеют отношение только к третьей теме. Она мне не интересна и участвовать в её обсуждении не планирую.
2 — Но зачем-то в упомянули об этом в самой статье
3 — т.е. вы даже не допускаете возможности, что можете ошибаться?
К конкретной вакансии описанная проблематика не имеет никакого отношения. Периодически участвую в качестве "второго номера" в собеседованиях на позицию проджект-менеджера, большинство описанных особенностей кандидатов актуальны и для неё.
Об отличиях функциональных возможностей Oracle и PostgreSQL в статье нет ни слова.
Я почти наверняка много в чем ошибаюсь. Но ставить диагнозы на основании статьи (!) - это еще круче чем лечить по фотографии.
1 — оказывается «проблема» для вас не в указанных должностях или опыте, а в целом в указании соискателями неких критериев, их знаниях, опыте и реакции на ваши действия
2 — а кто сказал про функциональные отличия?
3 — я в принципе теоретизирую, и пытаюсь рассмотреть ситуацию с разных сторон, а вот вы поставили диагноз после 20 собеседований, о чем и написали статью.
1) Отсутствие рефлексии относительно используемых инструментов
1,5 - 3 года - это очень малый срок, чтобы начать рефлексировать по-поводу используемых инструментов. Это всего лишь 1-3 полноценных проекта. Где можно столкнуться с REST в новой архитектуре и с SOAP немного в интеграциях какого-нибудь легаси, например. Понятно, что REST будет восприниматься как "модно, быстро, молодежно", а SOAP - нет.
2) Неумение формулировать определения
А вот это реально проблема у молодежи. Я обычно отправлял главу из "Системы Логики" Джона Стюарта Милля на почитать, когда вижу, что аналитик не умеет формулировать определения.
(Логику в среднюю школу, да и в ВУЗы по-нормальному, ясное дело, не вернут, т.к. после этого сломаются все механизмы управления государством)
3) Отсутствие мотивации к самостоятельному изучению профессии
Это последствия широко распространившегося мифа что все в IT меняется очень быстро, поэтому незачем что-то изучать глубоко. И тут есть резон, за 20 лет сменилась масса подходов.
+ очень трудно самостоятельно разобраться, что же действительно изучать. Информации так много, что выбрать ключевое крайне сложно самостоятельно.
4) Неумение смотреть на ситуацию «сверху»
Это умение появляется (либо не появляется) как раз после 3 лет практики обычно, и очень сильно зависит от этот практики, ведь на некоторых проектах можно 3 года детальные спеки на формочки писать, и ничего другого более не видеть. И это да, многолетний уже опыт. Уже не джун.
К сожалению, многие до сих пор считатают, что "аналитики - это же не джависты, три месяца поучить и будут спеки писать одна за другой". Нет. Это не так :)
5) Короткая память
К этому приводит, в том числе, постоянный поток информации, ротация проектов, задач и т.п. - пресловутые игры в "многозадачность" одновременно со "стрессоустойчивостью" и "проактивной позицией" (в результате - дефицит сна у исполнителей).
С другой стороны, зачем помнить то, что не потребуется прямо здесь и прямо сейчас?
Ну и опять же, не надо идеализировать "длинную память". Вот я помню, что примерно 20 лет назад рисовал что-то в ARIS. Но с тех пор ARIS практически вышел из употребления. Зачем мне его помнить, если заказчики хотят BPMN?
Помнить свои проекты до двух лет - это абсолютно нормально. Помнить больше - совершенно не обязательно. Какие-то воспоминания могут быть даже и вредны.
6) Не подтверждаются "ключевые навыки", заявленные в резюме
Это печально.
7) Отсутствие понимания что такое «анализ»
Дефекты нашего образования. И отсутствия самообразования.
8) Отсутствие реакции на обратную связь от собеседника
И это тоже печально.
9) Нет планирования своего профессионального развития
Ну тут несколько проблем. С одной стороны, если кандидат не отличает анализ от синтеза и требование от стейкхолдера, но о планировании развития ему говорить рано. С другой стороны, а куда аналитику развиваться? Джун, мидл, старший, ведущий и ... ведущий до пенсии? ) "Мы предлагаем вам стабильный оклад и возможности горизонтального роста компетенций в проектах связанных с автоматизацией документооборота в государственном секторе", угу, отличная перспектива развития )))
угу, отличная перспектива развитияМожете поделиться, чем плох горизонтальный рост компетенций? Ведь за это немало приплачивают.
Он хорош до тех пор, пока не начнете сталкиваться с отказами по мотивам "overqualified", эйджизмом и запросами о скидке "у вас опыт действительно большой, но к нашему проекту нерелевантный, поэтому сколько вы может уступить?".
У позиции есть зарплатная вилка, у вилки есть верхняя планка, и выше этой планки никакой горизонтальный рост компетенций прыгнуть не поможет.
Поэтому не тешьте себя иллюзиями, открывайте свой бизнес :)
Он хорош до тех пор, пока не начнете сталкиваться с отказами....Это да, часто это приводит к смене работы, но все равно на бОльшую з/п.
Поэтому не тешьте себя иллюзиями, открывайте свой бизнесОбычно это уже после опыта работы в нескольких разных конторах))
Поэтому не тешьте себя иллюзиями, открывайте свой бизнес :)
и с удивлением обнаружите что топменеджер вы фиговый, хотя и программист отличный… а обнаружите только спустив все деньги и влетев в долги
на самом деле путь наверх есть, в топменеджеры, и это будет бОлее реально чем поднять с нуля бизнес и стать крутым дядькой, это только кажется что начальник сидит и бабки гребет, а лиды сами толпой сыплятся, а продажники только и успевают отгружать заказы
на самом деле путь наверх есть, в топменеджеры, и это будет бОлее реально чем поднять с нуля бизнес и стать крутым дядькой
Думаю что сейчас этот путь без половых связей для человека вне тусовки олигархов закрыт совсем, даже по сравнению со "святыми 90ми".
Знаю прецеденты роста до уровня примерно "вице-президент крупного банка"
Без всяких "половых связей" и дяди-депутата
Реально, но сложно
Вице- бывают разные. Мне доводилось в 2010 году работать в Штатах в конторе, где такой титул получили сразу 4 девелопера :))))))). Это был такой способ не повышать им жалованье, а просто сыграть на понтах. Как по мне, такие вице-ХХХ - это типа военного инженера или научного работника в звании полковника, но при этом без командования л/с - т.к. как полковник он просто плюшевый, чисто для бюрократических целей получивший 3 звезды и папаху.
Статья понравилась, но я считаю, что требования на мидл-аналитика у вас кое-где избыточны (все комментарии не читал, возможно уже писали):
«Чем отличается А от В? В каких ситуациях лучше применять А, а в каких В?» <.....> у вас в опыте указаны PostgreSQL и Oracle
Если ждёте ответа, что нужно оценивать условия использования системы и тд и тп, то это вопрос для архитектора, который может выбрать инструмент. Аналитик инструмент не выбирает, так что вопрос считаю некорректным (разве что вы хотите оценить потенциал роста аналитика в архитектора).
Перед тем как начать что-то делать, полезно оглядеться вокруг и понять - где я нахожусь, что вообще происходит и зачем мне это делать. Это полезное правило,
Правило полезное, но джуну и мидлу целеполагание должен спустить продуктовый менеджер или архитектор, или кто у вас этой задачей занимается. Кажется, что задача мидла, если и посмотреть на окружение, то всё же чтобы учесть его наравне со словами стейкхолдеров.
Не подтверждаются "ключевые навыки", заявленные в резюме
Пусть сначала HR не будут отклонять резюме, в которых указано 5, а не 50 навыков, тогда и поговорим :-)
Отсутствие мотивации к самостоятельному изучению профессии
Об этом точно писали выше - не все хотят беспрерывно расти, а для поддержания текущего уровня достаточно работы и статей с хабра. Вас может не устраивать такой кандидидат, но в каких-то командах нужен просто молоток, чтобы забивать гвозди.
Добрый день!
Интересная статья, спасибо, но со многими пунктами не соглашусь. Ниже ряд из них приведу, но их гораздо больше, и напишу почему с ними не согласен:
1) Отсутствие понимания технологий, нежелание разбираться в особенностях того или иного инструмента (пример с Post и Oracle):
На хабре пару лет назад наткнулся на статью, как другой автор проводит собеседования, и там была очень крутая мысль, что помимо оценки его профессиональных качеств, необходимо еще учитывать его роль и обязанности, для которых вы собственно нанимаете сотрудника. То есть в чем польза человека, который знает в совершенстве язык программирования, если он будет заниматься пресэйлом или РП, не переплатите ли Вы за те скиллы, которые не требуются Вам в данный момент. То есть, конечно, это все неплохо, но не критично.
И наоборот, у меня есть огромное количество коллег, которые могут закрыть 90% задач по проекту, но при этом без понятия что такое база данных и чем они отличаются друг от друга. Я сам без понятия)
Здесь надо еще учитывать, что нанимая такого рода увлеченных людей, Вы вряд ли уговорите их годами заниматься однообразными задачами, все время придется подкидывать им интересные проекты и при отсутствии таких они без сожаления покинут вашу компанию (сам такой :))
2) Неумение формулировать определения:
бесполезный навык, который скорее говорит о Вас, как о не совсем адекватном работодателе. Р. Фейнман говорил, что вы тогда разбираетесь в своем деле, когда можете объяснить это ребенку, а ребенок вряд ли поймет сухой и казенный язык. В чем проблема растянуть определение на небольшой рассказ, не пытаясь уместить свою мысль в небольшое предложение?)
3) Неумение смотреть на ситуацию «сверху»:
людей с таким навыком очень мало, и они явно не ходят по собеседованиям на миддл-аналитика.
Общее впечатление от автора статьи, что довольно редкостный зануда, который будет тебя поправлять в разговоре, по 10 раз требовать переформулировать вопрос/ответ и все в таком духе) Сталкивался с такими людьми не раз: багаж знаний неплохой, но желания работать в команде с такими людьми не было
Неумение формулировать определения
Отсутствие мотивации к самостоятельному изучению профессии
Неумение смотреть на ситуацию «сверху»
Отсутствие понимания что такое «анализ»
поработав несколько лет в техподдержке продавана АСУТПшных железок могу сказать, что:
1) 90% обращающихся (особенно по телефону или в чате) с трудом могут сформулировать свои мысли, что задать вопрос. А это, на минуточку, казалось бы инженерно-технические кадры, а не повариха с лесоповала. В подписях email'ов мелькают «технический директор», «начальник всех инженеров», «инженер-программист», «к.т.н.», «проектировщик отдела АСУТП» и т.п.
2) вопрос не обязан начинаться с вопросительного слова и заканчиваться вопросительным знаком и знаки препинания сам расставь, раз такой умный
3) «не буду я читать документацию! ах она еще и на английском!, ты мне сразу скажи как это сделать»
4) совсем не обязательно мыслить структурно, категориями (а-ля «источник данных — передатчик данных — обработчик данных — визуализатор данных»), достаточно «ничего не работает»
Тоже собеседовал большое количество аналитиков разных уровней. Аналитиков с небольшим опытом обычно прошу подробно рассказать об опыте, что конкретно он/она делал на проекте. Стараюсь задавать много дополнительных вопросов, чтобы прощупать человека.
Также даю Json с ошибками и прошу найти в нем все ошибки.
По теории у меня есть отдельный файлик, в котором я отмечаю знания человека по пунктам (требования, базы данных, интеграции, SQL и тп). Обязательно спрашиваю, какие ошибки делал человек в работе и как их исправлял.
Стараюсь вывести человека максимально на диалог, чтобы понять структуру его/ее мышления
REST и SOAP, в чем разница?
Если хотите, могу пройти ваше собеседование
Статья отличная. Я как разработчик постоянно вижу такие пробелы в навыках аналитиков, с которыми работаю. Я бы только заключение вынес в начало статьи чтобы было сходу понятно, для кого и почему она будет полезна.
Смотрите, у вас в опыте указаны PostgreSQL и Oracle. И то, и другое – системы управления реляционными базами данных, используются для решения схожих задач. Но PostgreSQL бесплатный, а Oracle стоит миллионы рублей. При этом всё равно находятся люди, которые покупают Oracle. Почему они это делают?
Ни разу не прозвучал достаточно полный и точный ответ.
suburg, ТС, откройте уже секрет: какой
Выше целых два примера были:
https://habr.com/ru/post/694478/comments/#comment_24836384
https://habr.com/ru/post/694478/comments/#comment_24836784
Они правда не очень понравились отдельным читателям потому что это "вода", но от миддл-аналитика большего ожидать сложно.
интересная статья, есть над чем джуну с опытом в 1,5 года подумать)
А какие виды мыслительных операций существуют? И из каких источников вы почерпнули эту информацию?
Спасибо за статью, имеет право на существование, как говорится.
Ваш собес не прошел бы. Голову такими вопросами не забиваю и никому тут не советую.
Не понятно, как эти ответы на них связаны с:
пониманием ЖЦ, этапов анализа требований и проектирования.
Умением видеть разные уровни абстракции, а также прыгать от частного к общему и обратно.
Писать красивую документацию, с трассировками и со всей фигней, чтоб потом никто страдал в поисках «как работает система сейчас на проде. Зачем и почему мы это делали??».
Понимаем, как и что нужно делать на обозначенных этапах, чтобы экономить деньги компании (иначе зачем компании выделенный
системныйаналитик требований+проектировщик)С понимаем, что аналитик не ЛПР на проекте, что он никак не лучше разрабов в части КАК делать, что нельзя додумывать требования/проблемы за пользователей и прочее.
И еще много всего (у меня большой опыт в этом всем)
Такого рода собесы лучше быстро покидать. На реальных задачах будет некомфортно с такими коллегами/руководителями. Если тянет в методологию/на подработку в вузы, то можно испытать такое интервью на себе, лишним не будет.
Критерий успеха поиска недорого мидла: Минимальная адекватность + соображалка (не обязательно быстрая) + опыт 1,5-2 в динамичной разработке + способность ответить на вопрос про негативные кейсы за плечами (если хз/не помню/все было гладко всегда, то лучше мимо, даже если остальное все норм)
Смотрите, у вас в опыте указаны PostgreSQL и Oracle. И то, и другое – системы управления реляционными базами данных, используются для решения схожих задач. Но PostgreSQL бесплатный, а Oracle стоит миллионы рублей. При этом всё равно находятся люди, которые покупают Oracle. Почему они это делают?
Такие вещи знают только люди, которые работают с этим продуктами не на уровне системных аналитиков, а на уровне инженеров. Когда самостоятельно занимаешься настройкой и поддержкой PGSQL и Oracle или другой проприетарной субд на крупном проекте, то начинаешь понимать, почему другое стоит миллионы. Так устроен человек, что пока сам не получит опыт, он не поймёт. Поэтому не стоит требовать от людей больше, чем они должны знать
>чтобы не забивать молотком шурупы
Забиваешь молотком шуруп для того чтобы он "встал в направление" и дальше докручиваешь отверткой.
Не благодари
Очередная "классическая" статья от работодателя, который закрывает 2+ вакансии одним человеком, и подает это под соусом "ах как люди измельчали, раньше было лучше", делая отсылки к ISO / классикам / Аристотелю / вставить нужное.
При этом знания проверяются из других предметных областей или задаются "книжные" вопросы, не имеющие никакого отношения к реально предстоящей работе. Я всегда радуюсь, когда рядовой сотрудник "должен" разбираться в СУБД … не хуже архитектора или разработчика СУБД или DBA.
Чем-то напоминает маркетинговые материалы некоторых ранее известных компаний, предлагающих унижения на тестах плюс ставки ниже рынка и переработки, но при этом опять же требующих быть разработчиком, админом, математиком, спортивным программистом и еще желательно уже иметь 10+ лет опыта только для входа.
На такое есть только два разумных ответа - или приводить любую цитату великого классика или просто разворачиваться и уходить.
Молодежь нынче пошла не та, или поиск системного аналитика «за 200»