Понятно что определение не идеально. Например паспорт или военный билет тоже под него подойдут. Или отрывной календарь. Его можно долго уточнять и расширять, чтобы отсечь схожие предметы, которые при этом не являются книгами. В результате получим максимально точное определение, длиной страниц на 10, которым совершенно невозможно пользоваться.
Это еще один аспект вопроса "дай определение" - сможет ли кандидат выделить только ключевые характеристики и не закопаться в незначимые мелочи.
Нет идеального определения, каждому нравится свой вариант. В BABOK своё определение, в книге Вигерса приводится своё, у Леффингуэлла своё.
С моей рабоче-крестьянской колокольни удачным кажется определение "Требование к ПО - это описание функции или свойства, которым должно обладать разрабатываемое ПО". По крайне мере мне из этого определения понятно что такое "требование".
Да, можно взять набор базовых терминов, объявить их самоочевидными и дальше из них конструировать остальные определения. Но это уже в отвлеченную науку пошло.
Но так далеко я не захожу, ограничиваюсь только одним уровнем. И прошу определения только для тех терминов, которые могу определить сам.
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для Oracle, а вот для PostgreSQL надо нанимать нового человека – его зарплату тоже нужно учитывать. То есть в каждом конкретном надо считать цену, и не факт что Oracle всегда будет дороже PostgreSQL.
По функциональности – на том уровне, на котором я их использовал, СУБД примерно равны – основной функционал РСУБД есть и там, и там. Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал. Плюс вопрос нужны ли они конкретному клиенту. Опять же надо смотреть по ситуации.
По качественным характеристикам – я слышал что Oracle более надежный и производительный, но на уровне слухов. Надо смотреть тесты/обзоры и сравнивать показатели производительности и надежности с требуемыми.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5, а про Oracle говорили давно. Подозреваю, что у Oracle более развитое community и больше специалистов. Это тоже может быть значимым фактором.
Итог - надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.
Насчет "переплатить за проприетарную СУБД" - это ведь сложный вопрос. Надо сравнивать не стоимость лицензий, а совокупную стоимость владения. И здесь уже бабушка надвое сказала что дороже будет.
Про цену лицензии в вопросе вообще лишняя информация, она не имеет значения для ответа.
Всё верно, только это не про выбор СУБД, а про то что надо не забыть собрать нефункциональные требования и передать их архитектору (или кто там занимается высокоуровневым проектированием) для принятия решения.
Вот вы ругаете аналитиков.. вот тут нужно идти к тому, в чью светлую голову пришло "начать новый проект" и к тому, кто выделил на это деньги.
Это тоже хороший ответ на кейс :) Найти спонсора/инициатора и спросить что ему на самом деле нужно. И после этого уже принимать решение что делать.
Я ровно про это и пишу - что кандидат прыгает в описанное в кейсе болото и пытается там как-то барахтаться, вместо того чтобы сделать шаг назад и подумать - надо ему вообще в это болото лезть или есть другой путь.
Ну я же не у каждого кандидата такое спрашиваю - только у тех, у кого в разделе "Ключевые навыки" указаны обе СУБД. Причем человек написал не просто SQL (что чаще было бы более точным), а конкретно Oracle или PostgreSQL - предполагается что он что-то знает и про СУБД.
Меня вполне устроит такой ответ:
Для обоих СУБД я писал только простые SQL-запросы, на таком уровне применения они аналогичны - принципиальной разницы я не заметил. Вероятно, есть какая-то разница в производительности, надежности или еще чем-то, но я не знаю какая именно - это вопрос к ДБА.
Про книги ваша позиция понятна, но как говорится "есть нюанс".
Если я правильно понял, то вы ПЕРЕСТАЛИ читать книги после того, как поняли что ничего нового из них не получаете. Но многие люди даже НЕ НАЧИНАЛИ их читать.
Ну не знаю, вообще-то все кроме зарплатных ожиданий тут как раз от джуна. Я не знаю, где вы видели миддлов с опытом 2-3 года, мне такие не попадались вроде.
Вероятно у нас просто разные границы между Junior и Middle - у вас стандарты выше. У меня много примеров, когда сотрудники в 2-3 годами опыта были Middle (по моей шкале). Граница между Junior и Middle - тема для отдельной холиварной статьи :)
опыт самостоятельного ведения проекта - А как вы его измеряете?
Здесь я просто имею в виду ситуацию, что кандидат ранее работал в команде, где был единственным аналитиком. То есть он сам ходил к заказчику собирать требования, сам составлял спецификацию, сам сдавал работу. В противовес ситуации, когда в команде было несколько аналитиков, и всегда был "старший товарищ" который нарезал задачи и контролировал качество. Понятно, что кандидат мог приврать и по факту роль "старшего товарища" мог выполнять менеджер или например старший разработчик, но это уже на совести кандидата.
Многие пункты из статьи как раз и показывают отсутствие "идейности" - причем не у "юниоров", а людей с опытом в несколько лет. Которые уже "распробовали" профессию и заявляют о желании дальше в ней развиваться.
Юниоры действительно разные бывают, но это совсем другая история.
Меня больше всего удивляет то, что кандидаты спокойно отвечают на вопрос "чем системный анализ отличается от бизнес-анализа" (т.е. находят различия между ними), но при этом не могут объяснить что такое "анализ" вообще (т.е. не видят сходств - что в них общего).
Про "синтез" часто задаю наводящий вопрос - "обычно анализ противопоставляют синтезу, помогает ли это вам сформулировать определение анализа?"
От Junior я жду только "соображалку" и жажду знаний, больше ничего :) Остальное дело наживное.
Но назвать Junior'ом кандидата, который имеет 2-3 года работы по профессии, опыт самостоятельного ведения проекта, и зарплатные ожидания в 200К, у меня язык не поворачивается. При таких вводных я ожидаю что это будет "полноценная боевая единица" - то есть Middle или почти Middle. Возможно здесь вопрос в границе между этими уровнями, это крайне дискуссионный вопрос.
Составлять четкие и ёмкие определения - сложно, с этим я полностью согласен. Но попытаться сформулировать какой-то вариант можно. По крайне мере выделить отличительные признаки.
P.S. Книга - это упорядоченный и сброшюрованный набор листов бумаги, содержащих тематически связанный текст и/или иллюстрации, под общей обложкой. Это если говорить про "книгу" как предмет.
Безусловно, первичный фильтр по стороны HR имеет место. Собеседовать всех кто откликается у меня просто не хватает ресурса - работать будет некогда.
Относительно качества этого фильтра - мне кажется что он достаточно качественный. По крайне мере когда мы обсуждаем пограничные ситуации, то как правило мнение и доводы совпадают. Я считаю HR с которыми работаю профессионалами в своей сфере и отношусь с уважением к их компетенциям.
Безусловно, есть ошибки и 1 рода, и 2 рода. Но не думаю что массовые.
Спасибо за статью, было познавательно узнать практический опыт - как работают с требованиями в разных компаниях.
Очень заинтересовал вопрос "менеджеров" - кто эти люди. У нас на проектах эти функции выполняют обычно 3 разных человека (иногда два, но чаще три). Кажется что нужно иметь много разных компетенций, чтобы делать всё это сразу с достаточным качеством.
Можете рассказать - какой у менеджеров обычно бекграунд, легко ли их нанимать, есть ли какая-то программа подготовки (курс молодого бойца)?
Спасибо за статью. Немного зацепил тезис про "пожарную смену методологии" - это может быть очень больно. Если в команде полноценно внедрен тот же SCRUM (с соблюдением и буквы, и духа), то отказаться от него "со следующего понедельника" - это боль и кровь.
Мне кажется что можно менять максимум подход к планированию - т.е. жестко зафиксировать состав беклога продукта, как-то его оценить и разбить по спринтам (хотя даже это с точки зрения SCRUM Guide сомнительное занятие). Изменение чего-то большего может привести к проблемам в команде.
Понятно что определение не идеально. Например паспорт или военный билет тоже под него подойдут. Или отрывной календарь. Его можно долго уточнять и расширять, чтобы отсечь схожие предметы, которые при этом не являются книгами. В результате получим максимально точное определение, длиной страниц на 10, которым совершенно невозможно пользоваться.
Это еще один аспект вопроса "дай определение" - сможет ли кандидат выделить только ключевые характеристики и не закопаться в незначимые мелочи.
Ага, для этого раньше использовались тестовые задания - посмотреть как человек пишет.
Сейчас, к сожалению, люди редко соглашаются делать тестовое, и этот этап отбора пришлось опустить.
Нет идеального определения, каждому нравится свой вариант. В BABOK своё определение, в книге Вигерса приводится своё, у Леффингуэлла своё.
С моей рабоче-крестьянской колокольни удачным кажется определение "Требование к ПО - это описание функции или свойства, которым должно обладать разрабатываемое ПО". По крайне мере мне из этого определения понятно что такое "требование".
Если будет вопрос - это в плюс
Если будет озвучено допущение - тоже в плюс
Если без вопросов будет выбран самый логичный вариант - тоже нормально
На троечку, если честно.
Пожелание - это примерно то же что и требование, только необязательное к исполнению.
Ну это вы прямо в онтологию пошли.
Да, можно взять набор базовых терминов, объявить их самоочевидными и дальше из них конструировать остальные определения. Но это уже в отвлеченную науку пошло.
Но так далеко я не захожу, ограничиваюсь только одним уровнем. И прошу определения только для тех терминов, которые могу определить сам.
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для Oracle, а вот для PostgreSQL надо нанимать нового человека – его зарплату тоже нужно учитывать. То есть в каждом конкретном надо считать цену, и не факт что Oracle всегда будет дороже PostgreSQL.
По функциональности – на том уровне, на котором я их использовал, СУБД примерно равны – основной функционал РСУБД есть и там, и там. Возможно, есть разница в каких-то специфических сценариях – точно сказать не могу, не использовал. Плюс вопрос нужны ли они конкретному клиенту. Опять же надо смотреть по ситуации.
По качественным характеристикам – я слышал что Oracle более надежный и производительный, но на уровне слухов. Надо смотреть тесты/обзоры и сравнивать показатели производительности и надежности с требуемыми.
Также могу отметить что про PostgreSQL стало слышно только последние лет 5, а про Oracle говорили давно. Подозреваю, что у Oracle более развитое community и больше специалистов. Это тоже может быть значимым фактором.
Итог - надо в каждом конкретном случае сравнивать СУБД по совокупности критериев (не только по цене) и выбирать более подходящую именно для требуемых задач.
Насчет "переплатить за проприетарную СУБД" - это ведь сложный вопрос. Надо сравнивать не стоимость лицензий, а совокупную стоимость владения. И здесь уже бабушка надвое сказала что дороже будет.
Про цену лицензии в вопросе вообще лишняя информация, она не имеет значения для ответа.
Всё верно, только это не про выбор СУБД, а про то что надо не забыть собрать нефункциональные требования и передать их архитектору (или кто там занимается высокоуровневым проектированием) для принятия решения.
Это тоже хороший ответ на кейс :) Найти спонсора/инициатора и спросить что ему на самом деле нужно. И после этого уже принимать решение что делать.
Я ровно про это и пишу - что кандидат прыгает в описанное в кейсе болото и пытается там как-то барахтаться, вместо того чтобы сделать шаг назад и подумать - надо ему вообще в это болото лезть или есть другой путь.
Ну я же не у каждого кандидата такое спрашиваю - только у тех, у кого в разделе "Ключевые навыки" указаны обе СУБД. Причем человек написал не просто SQL (что чаще было бы более точным), а конкретно Oracle или PostgreSQL - предполагается что он что-то знает и про СУБД.
Меня вполне устроит такой ответ:
Но даже такой редко бывает...
Про книги ваша позиция понятна, но как говорится "есть нюанс".
Если я правильно понял, то вы ПЕРЕСТАЛИ читать книги после того, как поняли что ничего нового из них не получаете. Но многие люди даже НЕ НАЧИНАЛИ их читать.
И это совсем другой коленкор.
Да, спасибо, опечатка. Речь про 20 собеседований, а не про 20 десятков. Поправил.
Вероятно у нас просто разные границы между Junior и Middle - у вас стандарты выше. У меня много примеров, когда сотрудники в 2-3 годами опыта были Middle (по моей шкале). Граница между Junior и Middle - тема для отдельной холиварной статьи :)
Здесь я просто имею в виду ситуацию, что кандидат ранее работал в команде, где был единственным аналитиком. То есть он сам ходил к заказчику собирать требования, сам составлял спецификацию, сам сдавал работу. В противовес ситуации, когда в команде было несколько аналитиков, и всегда был "старший товарищ" который нарезал задачи и контролировал качество.
Понятно, что кандидат мог приврать и по факту роль "старшего товарища" мог выполнять менеджер или например старший разработчик, но это уже на совести кандидата.
Не очень понял ваше сообщение.
Многие пункты из статьи как раз и показывают отсутствие "идейности" - причем не у "юниоров", а людей с опытом в несколько лет. Которые уже "распробовали" профессию и заявляют о желании дальше в ней развиваться.
Юниоры действительно разные бывают, но это совсем другая история.
Меня больше всего удивляет то, что кандидаты спокойно отвечают на вопрос "чем системный анализ отличается от бизнес-анализа" (т.е. находят различия между ними), но при этом не могут объяснить что такое "анализ" вообще (т.е. не видят сходств - что в них общего).
Про "синтез" часто задаю наводящий вопрос - "обычно анализ противопоставляют синтезу, помогает ли это вам сформулировать определение анализа?"
От Junior я жду только "соображалку" и жажду знаний, больше ничего :) Остальное дело наживное.
Но назвать Junior'ом кандидата, который имеет 2-3 года работы по профессии, опыт самостоятельного ведения проекта, и зарплатные ожидания в 200К, у меня язык не поворачивается. При таких вводных я ожидаю что это будет "полноценная боевая единица" - то есть Middle или почти Middle. Возможно здесь вопрос в границе между этими уровнями, это крайне дискуссионный вопрос.
Составлять четкие и ёмкие определения - сложно, с этим я полностью согласен. Но попытаться сформулировать какой-то вариант можно. По крайне мере выделить отличительные признаки.
P.S. Книга - это упорядоченный и сброшюрованный набор листов бумаги, содержащих тематически связанный текст и/или иллюстрации, под общей обложкой. Это если говорить про "книгу" как предмет.
Безусловно, первичный фильтр по стороны HR имеет место. Собеседовать всех кто откликается у меня просто не хватает ресурса - работать будет некогда.
Относительно качества этого фильтра - мне кажется что он достаточно качественный. По крайне мере когда мы обсуждаем пограничные ситуации, то как правило мнение и доводы совпадают. Я считаю HR с которыми работаю профессионалами в своей сфере и отношусь с уважением к их компетенциям.
Безусловно, есть ошибки и 1 рода, и 2 рода. Но не думаю что массовые.
Спасибо за статью, было познавательно узнать практический опыт - как работают с требованиями в разных компаниях.
Очень заинтересовал вопрос "менеджеров" - кто эти люди. У нас на проектах эти функции выполняют обычно 3 разных человека (иногда два, но чаще три). Кажется что нужно иметь много разных компетенций, чтобы делать всё это сразу с достаточным качеством.
Можете рассказать - какой у менеджеров обычно бекграунд, легко ли их нанимать, есть ли какая-то программа подготовки (курс молодого бойца)?
Спасибо за статью. Немного зацепил тезис про "пожарную смену методологии" - это может быть очень больно. Если в команде полноценно внедрен тот же SCRUM (с соблюдением и буквы, и духа), то отказаться от него "со следующего понедельника" - это боль и кровь.
Мне кажется что можно менять максимум подход к планированию - т.е. жестко зафиксировать состав беклога продукта, как-то его оценить и разбить по спринтам (хотя даже это с точки зрения SCRUM Guide сомнительное занятие). Изменение чего-то большего может привести к проблемам в команде.