Size: a a a

Архитектура ИТ-решений

2020 May 04

S

Sergey in Архитектура ИТ-решений
начиная с марта какой день недели стал стираться уже... есть день и ночь  - сутки прочь
источник

MS

Maxim Smirnov in Архитектура ИТ-решений
Надо было добавить вариант: проектируете ли вы что-то сейчас. Я вот тоже работаю, но делаю онлайн-курс. Вроде и про архитектуру, но ничего полезного не проектирую
источник
2020 May 05

ОИ

Олег Игонин... in Архитектура ИТ-решений
Немного баловства или идея, как можно оценить навыки:
1. Берём основные направления работы  (в примере указаны примерно).
2. По каждому направлению формируем перечень общих вопросов, которые встречались/встречаются в работе IT-отдела компании.
3. Опрашиваем и оцениваем.
4. Проставляем в таблицу значения, где 1 - это самый слабое направление (относительно остальных), а 5 -самое сильное.
5. Генерируем диаграмму и прикладываем к резюме.
6. Сопоставляем с ожиданиями и прикидываем прочие требования.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
А если есть необходимость перекрыть большую часть направлений, а нет того самого универсального специалиста, то тут могут помочь два! Тогда берём и накладываем. Сразу видно где проседаем и у кого какие будут должностные обязанности. Оптимально перекрыть большую часть умений.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Немного баловства или идея, как можно оценить навыки:
1. Берём основные направления работы  (в примере указаны примерно).
2. По каждому направлению формируем перечень общих вопросов, которые встречались/встречаются в работе IT-отдела компании.
3. Опрашиваем и оцениваем.
4. Проставляем в таблицу значения, где 1 - это самый слабое направление (относительно остальных), а 5 -самое сильное.
5. Генерируем диаграмму и прикладываем к резюме.
6. Сопоставляем с ожиданиями и прикидываем прочие требования.
А на основе чего выявлять направления работы?
Например, компетенции специалиста в рамках профиля его специальности (т.е. оси определяем в соответствии с каким-то принятым стандартом). Или же проектные роли в команде/проекте. Например, человек себя обычно позиционирует как системного аналитика, но в рамках конкретного проекта требуется закрыть определенные роли, и картинка из резюме может не иметь нужной оси.
источник

M

Miras in Архитектура ИТ-решений
Олег Игонин
А если есть необходимость перекрыть большую часть направлений, а нет того самого универсального специалиста, то тут могут помочь два! Тогда берём и накладываем. Сразу видно где проседаем и у кого какие будут должностные обязанности. Оптимально перекрыть большую часть умений.
тимлиды вроде что-то подобное делают, чтобы определить в каких местах bus-factor низкий
источник

M

Miras in Архитектура ИТ-решений
ну и потом стараются давать задачи разным людям в зонах кода, где bus-factor низкий
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
А на основе чего выявлять направления работы?
Например, компетенции специалиста в рамках профиля его специальности (т.е. оси определяем в соответствии с каким-то принятым стандартом). Или же проектные роли в команде/проекте. Например, человек себя обычно позиционирует как системного аналитика, но в рамках конкретного проекта требуется закрыть определенные роли, и картинка из резюме может не иметь нужной оси.
Можно без проблем сделать таблицу под конкретную вакансию. Таблица даст возможность подумать об ожиданиях нанимателя, сформировать скоуп вопросов и визуализировать результат. Скоуп можно держать отдельно по каждому направлению.
Как узнать какие направления потребуются? наверное стоит взять горизонт планирования на 6+ месяцев, прикинуть какие там задачи будут, декомпозировать их на выполняемые функции роли архитектора, а также добавить к ним текущие проблемы (например, контроль качества, описание требований, поддержка договорённости с партнёрами, код-ревью и прочее). Обычно проблемы видны на уровне руководства, если оно получает обратную связь.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Единственное, непонятны критерии самооценки. Человек может быть к себе критичен. А другой - нет.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
Единственное, непонятны критерии самооценки. Человек может быть к себе критичен. А другой - нет.
Ну, вы как-то на экзамене сдаёте предметы? Тут также. Пускай критичен, но если рассказал о том, что надо знать, да ещё в детали уполз, то значит знает. Другой вопрос, что есть куча дополнительных факторов - характер человека, лидерство, адекватность, и т.д.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Ну, вы как-то на экзамене сдаёте предметы? Тут также. Пускай критичен, но если рассказал о том, что надо знать, да ещё в детали уполз, то значит знает. Другой вопрос, что есть куча дополнительных факторов - характер человека, лидерство, адекватность, и т.д.
А, то есть не сам кандидат себя оценивает. Понятно
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
А, то есть не сам кандидат себя оценивает. Понятно
Специалист, который оценивает сам себя - сферический конь в вакууме. Оценивать надо относительно чего-то. Можно сделать несколько наборов для оценки, но они не будут отображаться текущую необходимость конкретной организации. Есть базовые вещи, мышление, стандартные технологии и кейсы. По ним может и стоит формировать общие направления.
источник

AO

Architector Of_Fate in Архитектура ИТ-решений
А в конце может получиться "выбери своего бойца".
И если брать несколько специалистов, то может случиться, что они не смогут трудиться вместе.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Специалистов всегда надо оценивать с разных сторон. Составить правильную команду не просто. Умения - лишь некоторая часть из параметров специалиста. Она просто говорит о том, что человек может, а чего не может сделать. А вот захочет ли - вопрос за скоупом этого обсуждения. =)
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Специалист, который оценивает сам себя - сферический конь в вакууме. Оценивать надо относительно чего-то. Можно сделать несколько наборов для оценки, но они не будут отображаться текущую необходимость конкретной организации. Есть базовые вещи, мышление, стандартные технологии и кейсы. По ним может и стоит формировать общие направления.
А вот было бы здорово уметь самого себя оценивать. Нам же надо понимать, как расти и насколько мы освоили навык.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
А вот было бы здорово уметь самого себя оценивать. Нам же надо понимать, как расти и насколько мы освоили навык.
Ну вот ты системный аналитик, у нас есть карта умений аналитиков. насколько она тебе помогает расти? Да, видно, что можно почитать, что можно поковырять. Но в конкретной организации будет котироваться конкретный скоуп навыков, пускай даже из этой таблицы. Только ты выучишь тонну ненужной информации, потратишь время и в конечном итоге, если сравнивать двух специалистов - того, что шёл от общего к частному и того, что шёл от частного к общему, быстрее окупится, найдёт работу и начнёт выдавать профит второй вариант.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Олег Игонин
Ну вот ты системный аналитик, у нас есть карта умений аналитиков. насколько она тебе помогает расти? Да, видно, что можно почитать, что можно поковырять. Но в конкретной организации будет котироваться конкретный скоуп навыков, пускай даже из этой таблицы. Только ты выучишь тонну ненужной информации, потратишь время и в конечном итоге, если сравнивать двух специалистов - того, что шёл от общего к частному и того, что шёл от частного к общему, быстрее окупится, найдёт работу и начнёт выдавать профит второй вариант.
Я больше про сам процесс оценивания себя. Как оценить, что ты могешь в этот навык. Какие у него уровни, градации, и как выяснить соответствие этим уровням.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Daria Kaftan
Я больше про сам процесс оценивания себя. Как оценить, что ты могешь в этот навык. Какие у него уровни, градации, и как выяснить соответствие этим уровням.
Пока ты не используешь этот навык в повседневной работе и получаешь результат - никак.
источник

ОИ

Олег Игонин... in Архитектура ИТ-решений
Ну вот есть навык architect view. Берёшь его, читаешь. Дальше берёшь процесс над которым работаешь и расширяешь спеку, описывая процесс с различных сторон. В какой-то момент понимаешь, что вот эта часть нужна тогда-то, а вот эта часть зачастую вообще не нужна. Что-то можно описывать в разных нотациях и на разных языках, в разной детализации и уровне абстракции. И в конечном итоге ты понимаешь, что есть конечные пользователи твоих документов, каждому типу пользователя, если он есть, требуется для выполнения его функций определённый тип view, оформленный в понятном для него формате. Вот тогда ты овладеваешь навыком.
источник

I

Irina in Архитектура ИТ-решений
Daria Kaftan
Я больше про сам процесс оценивания себя. Как оценить, что ты могешь в этот навык. Какие у него уровни, градации, и как выяснить соответствие этим уровням.
Система не может оценить саму себя :)
источник