По первому пункту - вы даёте просто отличный ответ на кейс. К сожалению такого ответа от кандидатов я не получаю.
По второму - ну вот вам пример, про область применения ложки и вилки. Кандидат озвучивает прошлый опыт: ложкой я ел грибной суп и манную кашу, а вилкой - спагетти. Это прекрасно, но для нормального ответа на вопрос стоит дать обобщение - что ложка нужна для жидкой пищи, а вилка - для твёрдой. Без обобщения ответ слабый.
Если вы про ГОСТ 34, то он на автоматизированные системы, а не на ПО. Поэтому ТЗ по ГОСТ 34 содержит много того, что не является требованием к ПО. Что вполне логично. Если про ГОСТ 19, то я признаться уже не помню что там в ТЗ.
Порядок разработки или порядок приемки - это не требование к самому ПО, это требование к процессу его создания. Их принято разделять. Требования к процессу создания ПО - это менеджерская история, аналитику они скорее для информации.
В вашей точке зрения есть своя правда. Но в том же babok или у Леффингуэлла определение термина "требование" приводится.
"Делюсь субъективными переживаниями" - совершенно верно, только личный опыт и никаких претензий на объективность. Насчет "завышенных зарплатных ожиданий" - на этом не акцентировался, не готов судить какой уровень зарплаты адекватный, а какой завышенный. Возможно где-то в другом месте нужен кандидат именно с этими навыками и его оторвут с руками. "Пригорело" - нет, ничего не пригорало, скорее удивление и легкое разочарование.
Я ищу на рынке кадры, которые эффективны в конкретных условиях. Что такое "эффективны" - тема для отдельной статьи, там много аспектов.
Функция системного аналитика - разработка и сопровождение требований к программному обеспечению. В профстандарте "Системный аналитик" нормально написано про это.
Лично имел дело с одним человеком, который знал только BPMN и использовал его для всего. И диаграммы состояний, и диаграммы взаимодействия, и потоки данных, и алгоритмы - все рисовал на BPMN. Понятно что часто стандарту это не всегда соответствовало, но понять было можно (приложил определенные когнитивные усилия).
Если бы в "ящике с инструментами" было больше нотаций - можно было бы под каждый случай выбирать наиболее подходящую. Это и более общепринято, и рисовать проще, и понимать легче. Но поскольку в ящике лежит только BPMN - имеем то что имеем.
Если не проверить наличие "глубокого анализа" (ну ладно, не глубокого, хотя бы какого-нибудь) и "системного подхода", то есть высокая вероятность набрать таких исполнителей, глядя на результаты работы которых хватаешься за голову и спрашиваешь - "ЗАЧЕМ ты это сделал?"
Не "ЧТО", а именно "ЗАЧЕМ". Потому что сделано может быть быстро, аккуратно и технически грамотно - к этому не придраться. А вот с целеполаганием и соответствием окружающей действительности - просто беда.
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
При проведении собеседований в те годы (как раз в 2012 году был первый опыт в роли интервьюера на позицию аналитика) упор был на техническую составляющую: на собесе составляли требования, рисовали различные диаграммы, прототипы и т.д.
С возрастом шкала оценки меняется - сейчас по технике спрашиваю буквально пару кейсов. Основная часть беседы - проверка способности к самостоятельному мышлению.
Так что да, это в том числе и старческое брюзжание. Сократ на обложке это подчеркивает.
Инструменты и технологии - дело наживное, тем более для СА. От Senior я бы ждал наличия какого-то набора инструментария, который является "продолжением руки". Причем не так важно какого именно - просто как подтверждение наличия опыта и "ремесла в руках". От других уровней - не так важно.
"Хорошая память" вообще не критерий, скорее "наличие навыка работы с информацией".
"Умение смотреть на ситуацию сверху", "формулировать определения" - это всё про одно и то же, про уровень мышления.
Мне кажется вы не учли контекст - "собеседование СА с опытом 1.5-3 года".
Пример ответа выше не претендует на фактологическую точность и не должен быть таковым - ну откуда СА это знать? Это то, что можно сказать на основании общей эрудиции, здравого смысла, базовых знаний SQL и общеупотребимых слухов - что и может быть в голове у СА среднего уровня или ниже.
Если человек не знает, но при этом даёт внятный ответ, при этом четко отделяя факты от допущений - это прямо медаль на грудь и оффер на собеседовании.
P.S. Ну и писать в одном посте сразу "Oracle тоже можно использовать бесплатно" и "если сравнивать EE с полным фаршем за сотни нефти" - как-то странно.
Понятно что определение не идеально. Например паспорт или военный билет тоже под него подойдут. Или отрывной календарь. Его можно долго уточнять и расширять, чтобы отсечь схожие предметы, которые при этом не являются книгами. В результате получим максимально точное определение, длиной страниц на 10, которым совершенно невозможно пользоваться.
Это еще один аспект вопроса "дай определение" - сможет ли кандидат выделить только ключевые характеристики и не закопаться в незначимые мелочи.
Нет идеального определения, каждому нравится свой вариант. В BABOK своё определение, в книге Вигерса приводится своё, у Леффингуэлла своё.
С моей рабоче-крестьянской колокольни удачным кажется определение "Требование к ПО - это описание функции или свойства, которым должно обладать разрабатываемое ПО". По крайне мере мне из этого определения понятно что такое "требование".
Да, можно взять набор базовых терминов, объявить их самоочевидными и дальше из них конструировать остальные определения. Но это уже в отвлеченную науку пошло.
Но так далеко я не захожу, ограничиваюсь только одним уровнем. И прошу определения только для тех терминов, которые могу определить сам.
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для Oracle, а вот для PostgreSQL надо нанимать нового человека – его зарплату тоже нужно учитывать. То есть в каждом конкретном надо считать цену, и не факт что Oracle всегда будет дороже PostgreSQL.
По функциональности – на том уровне, на котором я их использовал, СУБД примерно равны – основной функционал РСУБД есть и там, и там. Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал. Плюс вопрос нужны ли они конкретному клиенту. Опять же надо смотреть по ситуации.
По качественным характеристикам – я слышал что Oracle более надежный и производительный, но на уровне слухов. Надо смотреть тесты/обзоры и сравнивать показатели производительности и надежности с требуемыми.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5, а про Oracle говорили давно. Подозреваю, что у Oracle более развитое community и больше специалистов. Это тоже может быть значимым фактором.
Итог - надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.
По первому пункту - вы даёте просто отличный ответ на кейс. К сожалению такого ответа от кандидатов я не получаю.
По второму - ну вот вам пример, про область применения ложки и вилки. Кандидат озвучивает прошлый опыт: ложкой я ел грибной суп и манную кашу, а вилкой - спагетти. Это прекрасно, но для нормального ответа на вопрос стоит дать обобщение - что ложка нужна для жидкой пищи, а вилка - для твёрдой. Без обобщения ответ слабый.
Если вы про ГОСТ 34, то он на автоматизированные системы, а не на ПО. Поэтому ТЗ по ГОСТ 34 содержит много того, что не является требованием к ПО. Что вполне логично. Если про ГОСТ 19, то я признаться уже не помню что там в ТЗ.
Понятно что это тема для отдельной дискуссии.
Порядок разработки или порядок приемки - это не требование к самому ПО, это требование к процессу его создания. Их принято разделять. Требования к процессу создания ПО - это менеджерская история, аналитику они скорее для информации.
В вашей точке зрения есть своя правда. Но в том же babok или у Леффингуэлла определение термина "требование" приводится.
"Делюсь субъективными переживаниями" - совершенно верно, только личный опыт и никаких претензий на объективность. Насчет "завышенных зарплатных ожиданий" - на этом не акцентировался, не готов судить какой уровень зарплаты адекватный, а какой завышенный. Возможно где-то в другом месте нужен кандидат именно с этими навыками и его оторвут с руками. "Пригорело" - нет, ничего не пригорало, скорее удивление и легкое разочарование.
Я ищу на рынке кадры, которые эффективны в конкретных условиях. Что такое "эффективны" - тема для отдельной статьи, там много аспектов.
Функция системного аналитика - разработка и сопровождение требований к программному обеспечению. В профстандарте "Системный аналитик" нормально написано про это.
Да
Канта я пробовал читать, но его честно не осилил
Очень тяжело идет :(
СУБД здесь не лучший пример.
Лично имел дело с одним человеком, который знал только BPMN и использовал его для всего. И диаграммы состояний, и диаграммы взаимодействия, и потоки данных, и алгоритмы - все рисовал на BPMN. Понятно что часто стандарту это не всегда соответствовало, но понять было можно (приложил определенные когнитивные усилия).
Если бы в "ящике с инструментами" было больше нотаций - можно было бы под каждый случай выбирать наиболее подходящую. Это и более общепринято, и рисовать проще, и понимать легче. Но поскольку в ящике лежит только BPMN - имеем то что имеем.
Если не проверить наличие "глубокого анализа" (ну ладно, не глубокого, хотя бы какого-нибудь) и "системного подхода", то есть высокая вероятность набрать таких исполнителей, глядя на результаты работы которых хватаешься за голову и спрашиваешь - "ЗАЧЕМ ты это сделал?"
Не "ЧТО", а именно "ЗАЧЕМ". Потому что сделано может быть быстро, аккуратно и технически грамотно - к этому не придраться. А вот с целеполаганием и соответствием окружающей действительности - просто беда.
Вот для этого нужен разум.
Отчасти вы правы - 10 лет назад такие вопросы (не про "перенос гор", а указанные в статье) мне бы показались абсолютно бесполезными и вообще верхом тупости - зачем это спрашивают, какое отношение это имеет к работе?
При проведении собеседований в те годы (как раз в 2012 году был первый опыт в роли интервьюера на позицию аналитика) упор был на техническую составляющую: на собесе составляли требования, рисовали различные диаграммы, прототипы и т.д.
С возрастом шкала оценки меняется - сейчас по технике спрашиваю буквально пару кейсов. Основная часть беседы - проверка способности к самостоятельному мышлению.
Так что да, это в том числе и старческое брюзжание. Сократ на обложке это подчеркивает.
Еще можно вспомнить про существование множества всех множеств, которое при этом не является подмножеством самого себя.
Вопрос множеств действительно ключевой в математике.
Инструменты и технологии - дело наживное, тем более для СА. От Senior я бы ждал наличия какого-то набора инструментария, который является "продолжением руки". Причем не так важно какого именно - просто как подтверждение наличия опыта и "ремесла в руках". От других уровней - не так важно.
"Хорошая память" вообще не критерий, скорее "наличие навыка работы с информацией".
"Умение смотреть на ситуацию сверху", "формулировать определения" - это всё про одно и то же, про уровень мышления.
Комментарий мощный, спасибо.
Признать я так далеко не заходил, и всегда считал GERAM и иже с ним не применимым на практике отвлеченным умствованием.
Но возможно я не прав и при достижении определенного уровня осознанности приходит понимание его роли и смысла.
Мне кажется вы не учли контекст - "собеседование СА с опытом 1.5-3 года".
Пример ответа выше не претендует на фактологическую точность и не должен быть таковым - ну откуда СА это знать? Это то, что можно сказать на основании общей эрудиции, здравого смысла, базовых знаний SQL и общеупотребимых слухов - что и может быть в голове у СА среднего уровня или ниже.
Если человек не знает, но при этом даёт внятный ответ, при этом четко отделяя факты от допущений - это прямо медаль на грудь и оффер на собеседовании.
P.S. Ну и писать в одном посте сразу "Oracle тоже можно использовать бесплатно" и "если сравнивать EE с полным фаршем за сотни нефти" - как-то странно.
А мне нравится "квартира" и "многоквартирный дом" в ЖК РФ:
Многоквартирный дом - здание, состоящее из двух и более квартир
Квартира - помещение в многоквартирном доме
По отдельности каждое определение выглядит нормально, а вместе какая то рекурсия.
Понятно что определение не идеально. Например паспорт или военный билет тоже под него подойдут. Или отрывной календарь. Его можно долго уточнять и расширять, чтобы отсечь схожие предметы, которые при этом не являются книгами. В результате получим максимально точное определение, длиной страниц на 10, которым совершенно невозможно пользоваться.
Это еще один аспект вопроса "дай определение" - сможет ли кандидат выделить только ключевые характеристики и не закопаться в незначимые мелочи.
Ага, для этого раньше использовались тестовые задания - посмотреть как человек пишет.
Сейчас, к сожалению, люди редко соглашаются делать тестовое, и этот этап отбора пришлось опустить.
Нет идеального определения, каждому нравится свой вариант. В BABOK своё определение, в книге Вигерса приводится своё, у Леффингуэлла своё.
С моей рабоче-крестьянской колокольни удачным кажется определение "Требование к ПО - это описание функции или свойства, которым должно обладать разрабатываемое ПО". По крайне мере мне из этого определения понятно что такое "требование".
Если будет вопрос - это в плюс
Если будет озвучено допущение - тоже в плюс
Если без вопросов будет выбран самый логичный вариант - тоже нормально
На троечку, если честно.
Пожелание - это примерно то же что и требование, только необязательное к исполнению.
Ну это вы прямо в онтологию пошли.
Да, можно взять набор базовых терминов, объявить их самоочевидными и дальше из них конструировать остальные определения. Но это уже в отвлеченную науку пошло.
Но так далеко я не захожу, ограничиваюсь только одним уровнем. И прошу определения только для тех терминов, которые могу определить сам.
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для Oracle, а вот для PostgreSQL надо нанимать нового человека – его зарплату тоже нужно учитывать. То есть в каждом конкретном надо считать цену, и не факт что Oracle всегда будет дороже PostgreSQL.
По функциональности – на том уровне, на котором я их использовал, СУБД примерно равны – основной функционал РСУБД есть и там, и там. Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал. Плюс вопрос нужны ли они конкретному клиенту. Опять же надо смотреть по ситуации.
По качественным характеристикам – я слышал что Oracle более надежный и производительный, но на уровне слухов. Надо смотреть тесты/обзоры и сравнивать показатели производительности и надежности с требуемыми.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5, а про Oracle говорили давно. Подозреваю, что у Oracle более развитое community и больше специалистов. Это тоже может быть значимым фактором.
Итог - надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.