Меня всегда раздражает в таких матрицах компетентности, то, что большой акцент делают на софтскилы, при этом никто четко не может объяснить их смысл и принцип распределения. Например "Системное мышление и логика. " у синьора, а типа до синьора можно мыслить не системно и не логично? Ну такая себе у вас аналитика получится тогда. "Вербальная коммуникация" У миддла тоже выглядит странно, у вас джуны 2-х летние, которые разговаривать не научились? ) И снова везде большой намек идет на то, что Аналитик еще и руководителем проекта должен подрабатывать на полставки.
Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK.
Скажите честно, часто в вашей профессиональной деятельности вам пригодилась классификация требований по BABOK?
Потому теория и улетучивается быстро, что в реальной жизни она как правило особо не нужна, либо нужна, но не вся. Почему именно по BABOK, а не по Вигерсу, к примеру? Оценивать специалиста по точному знанию академических формулировок - хорошо подходит для отсева джунов и студентов, но миддл+ специалистов спрашивать базовую теорию - не самая лучшая идея, особенно если это теория в вакууме. Есть тонкая грань, между реально необходимой в работе базой и теми знаниями, которые вам кажутся обязательными. Вы считаете, что каждый аналитик обязан прочитать BABOK, я встречался неоднократно с мнением от заслуженных лидов, что до синьор+ уровня к этому талмуду вообще нельзя прикасаться, больше вреда будет. Опять таки, вы считаете, что классификация требований по BABOK -маст хев, я например, считай, что по Вигерсу больше подходит для практических задач.
Я помню лет 10 назад, когда я был еще совсем зеленым, но уже начинал путь на руководящих ролях и проводил первые собеседованиях я грешил тем, что спрашивал вопросы по каким-то фактам, которые сам только недавно узнал, и в последующим так же благополучно забыл. Потом уже с опытом понял, что есть определенные вопросы - маркеры, которые показывают общую адекватность и знания, но большинство "теоретических" вопросов вообще ни о чем не говорит. У меня давно появилась интересная мысль, но к сожалению времени, возможности и решимости нет, что бы ее проверить - провести инвертированное интервью, попросить кандидата представить, что мы поменялись местами, и что он должен провести техническое интервью у тебя. Мне кажется по тем вопросам, которые задал бы кандидат и какие ответы бы он на них ждал гораздо больше бы сказало о кандидате, чем лотерея попадешь ил не попадешь ты в конкретные знания конкретного человека, ведь все ранво нет идеальных людей, которые знают абсолютно все.
А я, будучи внуком главного бухгалтера, которая постоянно работала дома, был свидетелем того, как девушки-молодушки и аналитики из разработки табунами в очередь выстраивались, что бы эта самая "тетка в возрасте" объяснила им все нововведения и изменения в очередном ПБУ, потому что "тетка в возрасте" еще не забыла, как мозгами думать и с фломастером внимательно изучала все тексты, а те привыкли доверять кнопки "сделай хорошо" и очень удивлялись, что кнопка не работает. Так что пока мы живем в динамическом мире, всегда будут те, кто умеет работать самостоятельно, иначе всех нас ждет светлое будущее с техно-жрецами, которые поклоняются духу-машине.
Архитектура (architecture) — описание (модель) основного устройства (структуры) и связей частей системы (физического или концептуального объекта или сущности). Примечание. Существует только два типа архитектур, имеющих отношение к интеграции предприятия, а именно:
a) системные архитектуры (называемые иногда архитектурами типа 1), действие которых распространяется на проектирование системы, например на компьютеризированную, являющуюся частью системы интеграции предприятия;
b) стандартные проекты предприятия (называемые иногда архитектурами типа 2), действие которых распространяется на организацию разработки и выполнения проекта, например интеграцию предприятия или другую программу развития предприятия.
[ГОСТ Р 54136-2010. Системы промышленной автоматизации и интеграция. Руководство по применению стандартов, структура и словарь]
архитекту́ра
сущ., ж., употр. сравн. часто
Морфология: (нет) чего? архитекту́ры, чему? архитекту́ре, (вижу) что? архитекту́ру, чем? архитекту́рой, о чём? об архитекту́ре
1. Архитектура — это искусство проектирования, постройки и оформления зданий.
Памятник классической архитектуры. | Современная архитектура.
= зодчество
2. Архитектура какого-либо объекта — это его строение, организация.
Архитектура литературного произведения. | Архитектура компьютерных микропроцессоров.
Толковый словарь русского языка Дмитриева.Д. В. Дмитриев.2003.
Так, ну посмотрел, и что не так? Вам не знакомо понятие многозначного термина? Или неизвестно, что язык развивается, и не надо ориентироваться только на словари Ожегова и Даля которые были изданы в прошлом и позапрошлом веке:
Мне кажется вы не правильно представляете себе обязанности аналитика. Как вы себе представляете "Просто соединить знания"? Нельзя просто взять и вписать слова одного и другого специалиста в один документ. С этим они бы и сами справились в каком-нибудь гугл-доке или конфлюенсе. Что бы "соединить знания" надо самому обладать этими знаниями, может чуть в меньшей степени чем исходный специалист, но куда шире по областям. Но это если бы задача была только в этом. Но вообще от аналитика требуется выработка и принятие оптимальных решений, и одинаково эффективно принимать и технические и бизнес-решения по процессу одному человеку может быть весьма не просто.
Может конечно в вашей компании позицию аналитика редуцировали до говорящего попугая, но вообще это не так. =)
Проблема в том. что это скорее баг. а не фича. Я почти не видел таких универсальных специалистов, есть либо сильна БА который слабо разбираются в технике, либо сильные СА, которые в БА разбираются больше интуитивно. И это в целом нормально, потому что обе сферы огромные и стать хорошим специалистом в обеих сферах почти нереально. При этом на мой взгляд не надо нормализовывать эту ситуацию подобными оправдывающими статьями.
"В заключение, несмотря на разделение на фронт-энд разработчика и бэк-енд разработчика, настоящий профессионал в сфере B2B должен обладать навыками обеих профессий и уметь сочетать их в рамках продукта, с которым он работает. Фулл-стек разработчик, обладающий глубоким пониманием фронта и бэка, является ценным активом для организации." Казалось бы одно и тоже, но почему-то от всех разработчиков не требуют быть фулл-стек. Наверно потому что глубокая экспертиза в чем-то не менее ценна чем поверхностное знание по многим областям. А то, что организации куда выгоднее и ценее платить одному спецйиалисту одну зарплату за работу двух специалистов - тут никаких сомнений.
С каких пор умение работать с данными стало софт-скиллом? Раньше эти навыки были обязательны для любого, кто занимался наукой от физики до психологии, а теперь выделили в отдельную профессию.
Первый пункт про недоверие к данным - это вообще за гранью. Как можно не доверять данным с которыми ты работаешь? в чем тогда смысл такой работы? Вопрос не про доверие, тут вопрос про умение их интерпретировать и работать с ними, при чем работать и на этапе их сборки. Вы привели примеры данных, которые на уровне здравого смысла некорректны. а что делать с данными, которые не так очевидны? А что делать с данными, которые корректны, но контринтуитивны? Тут надо задаваться всегда вопросом о методике сбора данных и правдивости источника, но чего точно не должен делать профессионал, так это опираться на личный опыт и "здравый смысл". Например я смотрю на статистику, где написано. что в мире 10% населения чернокожие и опираясь на личный опыт могу сказать. что ну это же бред, я за всю жизнь их видел человек 10, тут явная ошибка в данных и наоборот, в статистике написано что 90% населения европеоиды и решают, что ну да, вполне соответствует моему опыту. все верно. Так что проверка данных - это нормальный процесс. а не вопрос доверия к ним.
Тоже самое и с корреляциями, в науке давно научились с ними работать, а специалисты по данным, вроде как, до сих пор удивляются. Любые корреляции данных в рамках эксперимента. которые не связаны с гипотезой могут быть только восприняты как предмет для отдельного исследования, но не как материал для вывода, потому что при сборе большого количества метрик очень высокая вероятность, что две метрики будут вести себя случайно похоже. Верно и обратное - если вы не видите прямой связи между метриками. это не значит. что ее нет, вопрос в интерпретациях.
Вот вам, например, интересные данные, которые согласно вашей статье нам нельзя нести заказчику - средняя продолжительность жизни вич-положительных превышает среднюю продолжительность жизни здоровых по состоянию на 2016 год. При этом процент хронических заболеваний у них выше и манифестация раньше. Согласитесь. с точки здравого смысла - это же бред. Ну и странная корреляция между высокой частотой хронических заболеваний и высокой длительностью жизни, что казалось бы должно быть наоборот. Но если мы как-раз таки займемся вопрос интерпретации и сбора данных, то выясним. что вич-положительные обращаются к врачам гораздо чаще и охотнее, чем их "здоровые" соседи, а значит получают помощь раньше, но и выявляют проблемы у них чаще и раньше, за счет более аккуратного слежения за здоровьем и регулярным медицинским процедурам, живут дольше.
Так что доверять данным можно и нужно, если вы качественно провели их проверку и это не вопрос софт-скиллов, это вполне себе хард-скилл исследовательская задача.
Вообще обычно не меняются, так как эти стрелки обозначали направление перемотки пленки, но с учетом. что перевернули шкалу прогресса трека, это может ввести в заблуждение. Вообще. как я думал в случае с музыкой эту шкалу тоже не переворачивают.
UPD: Проверил, ради интереса, Apple music со мной согласен. Шкала громкости у них инвертирована, шкала прогресса песни нет, и соответственно кнопки означают направление прокрутки правильное.
EPC - хорошая нотификация, ее плюс, что она максимально понятна и в принципе ее можно спокойно показывать и не техническим специалистам. Главное не забывать, что она не просто так называет Event-driven в этом ее принцип, чередование события и функции реакции на это событие которое порождает следующее событие.
Sequence диаграмма из UML - однозначно обязательна к изучению и использованию. Самая нужная и удобная диаграмма взаимодействия между системами. Остальные UML по желанию, есть полезные, но эту прям в первую очередь.
С4 - для описания архитектуры системы. Тоже достаточно простая и наглядная нотация. ПО сравнению с конкурентами не выглядит как пережиток конструкторских бюро из 70-х. )
Это по крайней мер то, что я чаще всего использую, а так по необходимости еще много всего есть, главное не забывать, что это все инструменты, а инструмент надо подбирать под задачи. серебрнную пулю так и не изобрели(
Но в свою защиту могу сказать, стандартизация это очень хорошо, но все-таки главное, чтобы разработчику была однозначно понятна задача.
Абсолютно верно, именно по этому и важна стандартизация, она позволяет нам быть уверенным в том, что Я, заказчик и разработчик понимаем эту диаграмму одинаково, потому что элементы диаграммы для нас значат одно и тоже, и нам не надо предварительно проговаривать ее целиком. Из опыта могу сказать, что не всегда то, что нам кажется однозначно понятным так же однозначно понятно другим и возникают абсолютно неожиданные интерпретации. Стандарты нотфикац3ии позволяют избежать таких ситуаций. По этому я часто встречал даже на курсах такое мнение, что не важны стандарты, главное что бы было понятно, и когда это правило в устоявшемся коллективе - это имеет место быть, когда такое начинают пропагандировать на уровне курсов - за такое надо бить палками ,потому что это просто упрощение ради доступности, что бы больше людей прогнать через курс и состричь больше бабла. А я с таким, к сожалению, сталкивался.
Так что для собственного роста лучше гнать от себя такие соблазнительные мысли и следовать золотому правилу: " Прежде чем научиться делать плохо - научитесь делать хорошо".
Но ведь это не EPC... И это в общем-то отражает всю суть происходящего. Заметно острая нехватка теоретической базы и фундамента. Это общая проблема большинства тех, кто пришел в ИТ и аналитику со стороны "из слесарей" (ни в коем случае не хочу обидеть слесарей, я со своими руками из области ниже поясницы вообще восхищаюсь людьми, которые могут что-то делать своими руками, просто это буквально название вашей статьи). Что бы корректно описать процесс и задачу это должно быть наглядно. а главное однозначно, а для этого необходимо мало-мальски придерживаться нотации, а не просто использовать похожие значки.
Понятно. =) Просто из статьи это непонятно и сразу настраивает на скептическое отношение к дальнейшему тексту, раз уже в начале идет смешение теплого с мягким. )
За все хорошее, против всего плохого. При чем тут системный анализ и аудит ИБ не понятно и статья это никак не объясняет. Статья в принципе ничего не объясняет, кроме общих фраз из любой брошюри любой компании, занимающейся ИБ.
Проблема только в том. что чтобы чатГПТ что-то вам ответил. он сначала должен обучиться на документации человека-оркестра.
Меня всегда раздражает в таких матрицах компетентности, то, что большой акцент делают на софтскилы, при этом никто четко не может объяснить их смысл и принцип распределения. Например "Системное мышление и логика. " у синьора, а типа до синьора можно мыслить не системно и не логично? Ну такая себе у вас аналитика получится тогда. "Вербальная коммуникация" У миддла тоже выглядит странно, у вас джуны 2-х летние, которые разговаривать не научились? ) И снова везде большой намек идет на то, что Аналитик еще и руководителем проекта должен подрабатывать на полставки.
Но и всякие спец.отсрочки за ИТ не работают с ИП. Понятно, что они довольно зыбкие, но пока есть.
Скажите честно, часто в вашей профессиональной деятельности вам пригодилась классификация требований по BABOK?
Потому теория и улетучивается быстро, что в реальной жизни она как правило особо не нужна, либо нужна, но не вся. Почему именно по BABOK, а не по Вигерсу, к примеру? Оценивать специалиста по точному знанию академических формулировок - хорошо подходит для отсева джунов и студентов, но миддл+ специалистов спрашивать базовую теорию - не самая лучшая идея, особенно если это теория в вакууме. Есть тонкая грань, между реально необходимой в работе базой и теми знаниями, которые вам кажутся обязательными. Вы считаете, что каждый аналитик обязан прочитать BABOK, я встречался неоднократно с мнением от заслуженных лидов, что до синьор+ уровня к этому талмуду вообще нельзя прикасаться, больше вреда будет. Опять таки, вы считаете, что классификация требований по BABOK -маст хев, я например, считай, что по Вигерсу больше подходит для практических задач.
Я помню лет 10 назад, когда я был еще совсем зеленым, но уже начинал путь на руководящих ролях и проводил первые собеседованиях я грешил тем, что спрашивал вопросы по каким-то фактам, которые сам только недавно узнал, и в последующим так же благополучно забыл. Потом уже с опытом понял, что есть определенные вопросы - маркеры, которые показывают общую адекватность и знания, но большинство "теоретических" вопросов вообще ни о чем не говорит. У меня давно появилась интересная мысль, но к сожалению времени, возможности и решимости нет, что бы ее проверить - провести инвертированное интервью, попросить кандидата представить, что мы поменялись местами, и что он должен провести техническое интервью у тебя. Мне кажется по тем вопросам, которые задал бы кандидат и какие ответы бы он на них ждал гораздо больше бы сказало о кандидате, чем лотерея попадешь ил не попадешь ты в конкретные знания конкретного человека, ведь все ранво нет идеальных людей, которые знают абсолютно все.
А я, будучи внуком главного бухгалтера, которая постоянно работала дома, был свидетелем того, как девушки-молодушки и аналитики из разработки табунами в очередь выстраивались, что бы эта самая "тетка в возрасте" объяснила им все нововведения и изменения в очередном ПБУ, потому что "тетка в возрасте" еще не забыла, как мозгами думать и с фломастером внимательно изучала все тексты, а те привыкли доверять кнопки "сделай хорошо" и очень удивлялись, что кнопка не работает. Так что пока мы живем в динамическом мире, всегда будут те, кто умеет работать самостоятельно, иначе всех нас ждет светлое будущее с техно-жрецами, которые поклоняются духу-машине.
Так, ну посмотрел, и что не так? Вам не знакомо понятие многозначного термина? Или неизвестно, что язык развивается, и не надо ориентироваться только на словари Ожегова и Даля которые были изданы в прошлом и позапрошлом веке:
Предложите альтернативу
Мне из российских вспоминаются только двое таких, это орк-подкастер и Дмитрий Бейл и у обоих аватары далеки от кошкодевочек.)
Более чем. Без технической базы и насмотренности будет тяжело
Мне кажется вы не правильно представляете себе обязанности аналитика. Как вы себе представляете "Просто соединить знания"? Нельзя просто взять и вписать слова одного и другого специалиста в один документ. С этим они бы и сами справились в каком-нибудь гугл-доке или конфлюенсе. Что бы "соединить знания" надо самому обладать этими знаниями, может чуть в меньшей степени чем исходный специалист, но куда шире по областям. Но это если бы задача была только в этом. Но вообще от аналитика требуется выработка и принятие оптимальных решений, и одинаково эффективно принимать и технические и бизнес-решения по процессу одному человеку может быть весьма не просто.
Может конечно в вашей компании позицию аналитика редуцировали до говорящего попугая, но вообще это не так. =)
Проблема в том. что это скорее баг. а не фича. Я почти не видел таких универсальных специалистов, есть либо сильна БА который слабо разбираются в технике, либо сильные СА, которые в БА разбираются больше интуитивно. И это в целом нормально, потому что обе сферы огромные и стать хорошим специалистом в обеих сферах почти нереально. При этом на мой взгляд не надо нормализовывать эту ситуацию подобными оправдывающими статьями.
"В заключение, несмотря на разделение на фронт-энд разработчика и бэк-енд разработчика, настоящий профессионал в сфере B2B должен обладать навыками обеих профессий и уметь сочетать их в рамках продукта, с которым он работает. Фулл-стек разработчик, обладающий глубоким пониманием фронта и бэка, является ценным активом для организации." Казалось бы одно и тоже, но почему-то от всех разработчиков не требуют быть фулл-стек. Наверно потому что глубокая экспертиза в чем-то не менее ценна чем поверхностное знание по многим областям. А то, что организации куда выгоднее и ценее платить одному спецйиалисту одну зарплату за работу двух специалистов - тут никаких сомнений.
С каких пор умение работать с данными стало софт-скиллом? Раньше эти навыки были обязательны для любого, кто занимался наукой от физики до психологии, а теперь выделили в отдельную профессию.
Первый пункт про недоверие к данным - это вообще за гранью. Как можно не доверять данным с которыми ты работаешь? в чем тогда смысл такой работы? Вопрос не про доверие, тут вопрос про умение их интерпретировать и работать с ними, при чем работать и на этапе их сборки. Вы привели примеры данных, которые на уровне здравого смысла некорректны. а что делать с данными, которые не так очевидны? А что делать с данными, которые корректны, но контринтуитивны? Тут надо задаваться всегда вопросом о методике сбора данных и правдивости источника, но чего точно не должен делать профессионал, так это опираться на личный опыт и "здравый смысл". Например я смотрю на статистику, где написано. что в мире 10% населения чернокожие и опираясь на личный опыт могу сказать. что ну это же бред, я за всю жизнь их видел человек 10, тут явная ошибка в данных и наоборот, в статистике написано что 90% населения европеоиды и решают, что ну да, вполне соответствует моему опыту. все верно. Так что проверка данных - это нормальный процесс. а не вопрос доверия к ним.
Тоже самое и с корреляциями, в науке давно научились с ними работать, а специалисты по данным, вроде как, до сих пор удивляются. Любые корреляции данных в рамках эксперимента. которые не связаны с гипотезой могут быть только восприняты как предмет для отдельного исследования, но не как материал для вывода, потому что при сборе большого количества метрик очень высокая вероятность, что две метрики будут вести себя случайно похоже. Верно и обратное - если вы не видите прямой связи между метриками. это не значит. что ее нет, вопрос в интерпретациях.
Вот вам, например, интересные данные, которые согласно вашей статье нам нельзя нести заказчику - средняя продолжительность жизни вич-положительных превышает среднюю продолжительность жизни здоровых по состоянию на 2016 год. При этом процент хронических заболеваний у них выше и манифестация раньше. Согласитесь. с точки здравого смысла - это же бред. Ну и странная корреляция между высокой частотой хронических заболеваний и высокой длительностью жизни, что казалось бы должно быть наоборот. Но если мы как-раз таки займемся вопрос интерпретации и сбора данных, то выясним. что вич-положительные обращаются к врачам гораздо чаще и охотнее, чем их "здоровые" соседи, а значит получают помощь раньше, но и выявляют проблемы у них чаще и раньше, за счет более аккуратного слежения за здоровьем и регулярным медицинским процедурам, живут дольше.
Так что доверять данным можно и нужно, если вы качественно провели их проверку и это не вопрос софт-скиллов, это вполне себе хард-скилл исследовательская задача.
Вообще обычно не меняются, так как эти стрелки обозначали направление перемотки пленки, но с учетом. что перевернули шкалу прогресса трека, это может ввести в заблуждение. Вообще. как я думал в случае с музыкой эту шкалу тоже не переворачивают.
UPD: Проверил, ради интереса, Apple music со мной согласен. Шкала громкости у них инвертирована, шкала прогресса песни нет, и соответственно кнопки означают направление прокрутки правильное.
EPC - хорошая нотификация, ее плюс, что она максимально понятна и в принципе ее можно спокойно показывать и не техническим специалистам. Главное не забывать, что она не просто так называет Event-driven в этом ее принцип, чередование события и функции реакции на это событие которое порождает следующее событие.
Sequence диаграмма из UML - однозначно обязательна к изучению и использованию. Самая нужная и удобная диаграмма взаимодействия между системами. Остальные UML по желанию, есть полезные, но эту прям в первую очередь.
С4 - для описания архитектуры системы. Тоже достаточно простая и наглядная нотация. ПО сравнению с конкурентами не выглядит как пережиток конструкторских бюро из 70-х. )
Это по крайней мер то, что я чаще всего использую, а так по необходимости еще много всего есть, главное не забывать, что это все инструменты, а инструмент надо подбирать под задачи. серебрнную пулю так и не изобрели(
Абсолютно верно, именно по этому и важна стандартизация, она позволяет нам быть уверенным в том, что Я, заказчик и разработчик понимаем эту диаграмму одинаково, потому что элементы диаграммы для нас значат одно и тоже, и нам не надо предварительно проговаривать ее целиком. Из опыта могу сказать, что не всегда то, что нам кажется однозначно понятным так же однозначно понятно другим и возникают абсолютно неожиданные интерпретации. Стандарты нотфикац3ии позволяют избежать таких ситуаций. По этому я часто встречал даже на курсах такое мнение, что не важны стандарты, главное что бы было понятно, и когда это правило в устоявшемся коллективе - это имеет место быть, когда такое начинают пропагандировать на уровне курсов - за такое надо бить палками ,потому что это просто упрощение ради доступности, что бы больше людей прогнать через курс и состричь больше бабла. А я с таким, к сожалению, сталкивался.
Так что для собственного роста лучше гнать от себя такие соблазнительные мысли и следовать золотому правилу: " Прежде чем научиться делать плохо - научитесь делать хорошо".
Но ведь это не EPC... И это в общем-то отражает всю суть происходящего. Заметно острая нехватка теоретической базы и фундамента. Это общая проблема большинства тех, кто пришел в ИТ и аналитику со стороны "из слесарей" (ни в коем случае не хочу обидеть слесарей, я со своими руками из области ниже поясницы вообще восхищаюсь людьми, которые могут что-то делать своими руками, просто это буквально название вашей статьи). Что бы корректно описать процесс и задачу это должно быть наглядно. а главное однозначно, а для этого необходимо мало-мальски придерживаться нотации, а не просто использовать похожие значки.
Понятно. =) Просто из статьи это непонятно и сразу настраивает на скептическое отношение к дальнейшему тексту, раз уже в начале идет смешение теплого с мягким. )
Видимо после статей вы все таки не до конца разобрались сравнивая отвертку со слоном.
За все хорошее, против всего плохого. При чем тут системный анализ и аудит ИБ не понятно и статья это никак не объясняет. Статья в принципе ничего не объясняет, кроме общих фраз из любой брошюри любой компании, занимающейся ИБ.