Комментарии 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 рода. Но не думаю что массовые.
попробуйте посмотреть отклоняемые резюме, хотя бы штук 10
Частая проблема кандидатов – длинная и неструктурированная речь с большим количеством деталей, незначимых для ответа на поставленный вопрос.
Услышав первый затянутый ответ, я переспрашиваю «Правильно ли я вас понял, что…» и повторяю ключевые мысли из ответа кандидата, но раз в десять короче и более структурированно – например, в формате нумерованного списка (во-первых, во-вторых, в третьих
Вот это типичная речевая манипуляция, которую любят детишки. Наговорить кучу бреда вокруг да около, авось что из этого бреда в сознании собеседника сложится куда надо. Самое поганое когда так себя ведут твои коллеги по работе. Еще более поганое когда 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 - имеем то что имеем.
Молодежь нынче пошла не та, или поиск системного аналитика «за 200»