Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для 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 сомнительное занятие). Изменение чего-то большего может привести к проблемам в команде.
Да, речь идёт в основном про различного рода бизнес-приложения - либо для внутренних пользователей организации, либо для иного ограниченного круга лица. Максимум речь шла о десятках тысяч конкурентных пользователей (на систему в целом) - и такой процесс моделирования данных был эффективен.
Есть речь идет о более высоких нагрузках - вероятно процесс должен как-то видоизмениться. Но как именно - из-за отсутствия собственного практического опыта предметно обсудить затрудняюсь.
Несколько раз подступался к использования онтологий в проектах, но ни разу полноценно не внедрил.
Либо онтология была космического размера и никем не использовалась — т.к. слишком сложно и непонятно зачем (а трудозатраты на её составление были существенными), либо она была примитивна и тоже не использовалась (т.к. всё это и так понятно).
То есть что-то рисовали на старте, а потом не актуализировали — так как никому не надо.
Крайне интересен опыт практического использования онтологий (например, на базе IDEF5) на проектах не связанных с темой ИИ.
Уважаемый автор, можете уточнить — был ли у вас опыт использования онтологий на реальных проектах? Какую пользу они там принесли?
Отношусь к UML как к «латыни программирования».
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
Неоднократно составлял такие таблицы — вот только цель была не «выбрать платформу», а «обосновать выбор платформы». Удачный подбор критериев и весов творит чудеса :)
Предложенная техника представляет интерес если веса определяют одни люди, а оценивают другие — причем независимо друг от друга. Тогда есть какая-то объективность в этом процессе и результат может быть неожиданным.
Я имел в виду именно опыт организации flow — когда задача последовательно проходит этапы «бизнес-анализа» и «системного анализа», которые выполняются разными людьми.
Вот ответ, который не требует специальных знаний, и после которого я бы аплодировал стоя:
При принятии решения о покупке учитываются цена, функциональность и качественные характеристики.
При сравнении цены некорректно сравнивать только цену лицензии. Например, для разных СУБД может потребоваться разное «железо», которое стоит по разному. Или например в компании уже есть ДБА для 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 сомнительное занятие). Изменение чего-то большего может привести к проблемам в команде.
Да, вы всё верно написали. Но у меня был вопрос не про приложения созданные на платформе 1С, а про саму платформу, которая поддерживает разные СУБД.
Приложения на платформе 1С понятно что используют абстракции предоставляемые платформой и далеки от конкретной СУБД.
Да, речь идёт в основном про различного рода бизнес-приложения - либо для внутренних пользователей организации, либо для иного ограниченного круга лица. Максимум речь шла о десятках тысяч конкурентных пользователей (на систему в целом) - и такой процесс моделирования данных был эффективен.
Есть речь идет о более высоких нагрузках - вероятно процесс должен как-то видоизмениться. Но как именно - из-за отсутствия собственного практического опыта предметно обсудить затрудняюсь.
Либо онтология была космического размера и никем не использовалась — т.к. слишком сложно и непонятно зачем (а трудозатраты на её составление были существенными), либо она была примитивна и тоже не использовалась (т.к. всё это и так понятно).
То есть что-то рисовали на старте, а потом не актуализировали — так как никому не надо.
Крайне интересен опыт практического использования онтологий (например, на базе IDEF5) на проектах не связанных с темой ИИ.
Уважаемый автор, можете уточнить — был ли у вас опыт использования онтологий на реальных проектах? Какую пользу они там принесли?
С одной стороны — это «мертвый язык», и успешного полноценного применения (когда UML — это основной инструмент проектирования, о чем мечтали авторы) ни разу не видел.
С другой стороны, изучение UML крайне полезно в плане переформатирования мозгов. Сама идея что приложение можно описать с разных точек зрения с помощью различных диаграмм UML (и то как эти диаграммы согласованы друг с другом) — для начинающих специалистов часто является революционной и двигает их вперед.
P.S. На практике применяю порядка 5 видов диаграмм UML — в основном в иллюстративных целях.
Предложенная техника представляет интерес если веса определяют одни люди, а оценивают другие — причем независимо друг от друга. Тогда есть какая-то объективность в этом процессе и результат может быть неожиданным.
Я имел в виду именно опыт организации flow — когда задача последовательно проходит этапы «бизнес-анализа» и «системного анализа», которые выполняются разными людьми.