Комментарии 6
Все-таки, почему вы ничего не говорите о работе с JIRA и CONFLUENCE? Поддержу автора, часто на собеседованиях у соискателях спрашивают о ER-диаграммах, которые по факту потом нигде не используются.
А как JIRA и CONFLUENCE относятся к моделированию и визуализации?
Если в confluence, то это встроенный плагин draw.io. Кстати, выше на одной из диаграмм приведен confluence, так же как и draw.io.
ER-диаграммы знать положено, ибо зная их, аналитик при проектировании системы мыслит соответствующим образом. Это просто проверка компетенций, вот и все. Мы тоже на собеседовании спрашивали знание UML, хотя его использование у нас в компании не обязательно. Прочитать Sequence диаграмму может даже не сведущий в этом языке (UML) специалист.
Спасибо за рейтинги конечно, всегда интересно такое видеть!
Слегка удивлен «популятностью» ER моделей. 1 человек, Карл?
На днях общался с архитектором Озона, там ER на мостике между IT и Бизнесом. Похожая картина «наземле» с несколькими крупными банками, крупным ретейлом.
Проще и «убойней», чем ER с их вороньими лапками на уровне концептуальной и уже производной физической модели надо искать.
Неужто Классика так просела в рейтингах?
Слегка удивлен «популятностью» ER моделей. 1 человек, Карл?
На днях общался с архитектором Озона, там ER на мостике между IT и Бизнесом. Похожая картина «наземле» с несколькими крупными банками, крупным ретейлом.
Проще и «убойней», чем ER с их вороньими лапками на уровне концептуальной и уже производной физической модели надо искать.
Неужто Классика так просела в рейтингах?
Круто, если это полезно)
К счастью, классика жива, это небольшой баг/фича нормализации данных, т.к. была возможность указывать свободные названия. Дело в том, что есть несколько видов entity relationship diagram, один из видов был использован в UML — диаграмма сущность-связь (ее выбрали 52 человека). Поэтому я решил не удалять это свободное название.
Подробнее можно посмотреть тут: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
К счастью, классика жива, это небольшой баг/фича нормализации данных, т.к. была возможность указывать свободные названия. Дело в том, что есть несколько видов entity relationship diagram, один из видов был использован в UML — диаграмма сущность-связь (ее выбрали 52 человека). Поэтому я решил не удалять это свободное название.
Подробнее можно посмотреть тут: en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
Можете объяснить на примере, с какими некорректностями в описаниях вакансий вы сталкивались? И как именно результаты данного опроса могут помочь HR их исправить?
1. конкретные ссылки искать не буду. Обычно это диаграммы и методы, которые вряд ли реально используются (по моему опыту и по статистике) или большой перечень нотаций, часто устаревших. Лично мне такой зоопарк показывал, что в компании не озаботились валидировать вакансию об реального руководителя — для меня это болезненный признак, а спрос позволял выбирать.
2. например, позволит не указывать просто «знание UML». Их больше 10 и все они вряд ли нужны. А вот нужную специалист к собеседованию выучит.
2. например, позволит не указывать просто «знание UML». Их больше 10 и все они вряд ли нужны. А вот нужную специалист к собеседованию выучит.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моделирование и визуализация при анализе и проектировании ИТ систем. И не только