Мне кажется вы не правильно представляете себе обязанности аналитика. Как вы себе представляете "Просто соединить знания"? Нельзя просто взять и вписать слова одного и другого специалиста в один документ. С этим они бы и сами справились в каком-нибудь гугл-доке или конфлюенсе. Что бы "соединить знания" надо самому обладать этими знаниями, может чуть в меньшей степени чем исходный специалист, но куда шире по областям. Но это если бы задача была только в этом. Но вообще от аналитика требуется выработка и принятие оптимальных решений, и одинаково эффективно принимать и технические и бизнес-решения по процессу одному человеку может быть весьма не просто.
Может конечно в вашей компании позицию аналитика редуцировали до говорящего попугая, но вообще это не так. =)
Проблема в том. что это скорее баг. а не фича. Я почти не видел таких универсальных специалистов, есть либо сильна БА который слабо разбираются в технике, либо сильные СА, которые в БА разбираются больше интуитивно. И это в целом нормально, потому что обе сферы огромные и стать хорошим специалистом в обеих сферах почти нереально. При этом на мой взгляд не надо нормализовывать эту ситуацию подобными оправдывающими статьями.
"В заключение, несмотря на разделение на фронт-энд разработчика и бэк-енд разработчика, настоящий профессионал в сфере B2B должен обладать навыками обеих профессий и уметь сочетать их в рамках продукта, с которым он работает. Фулл-стек разработчик, обладающий глубоким пониманием фронта и бэка, является ценным активом для организации." Казалось бы одно и тоже, но почему-то от всех разработчиков не требуют быть фулл-стек. Наверно потому что глубокая экспертиза в чем-то не менее ценна чем поверхностное знание по многим областям. А то, что организации куда выгоднее и ценее платить одному спецйиалисту одну зарплату за работу двух специалистов - тут никаких сомнений.
С каких пор умение работать с данными стало софт-скиллом? Раньше эти навыки были обязательны для любого, кто занимался наукой от физики до психологии, а теперь выделили в отдельную профессию.
Первый пункт про недоверие к данным - это вообще за гранью. Как можно не доверять данным с которыми ты работаешь? в чем тогда смысл такой работы? Вопрос не про доверие, тут вопрос про умение их интерпретировать и работать с ними, при чем работать и на этапе их сборки. Вы привели примеры данных, которые на уровне здравого смысла некорректны. а что делать с данными, которые не так очевидны? А что делать с данными, которые корректны, но контринтуитивны? Тут надо задаваться всегда вопросом о методике сбора данных и правдивости источника, но чего точно не должен делать профессионал, так это опираться на личный опыт и "здравый смысл". Например я смотрю на статистику, где написано. что в мире 10% населения чернокожие и опираясь на личный опыт могу сказать. что ну это же бред, я за всю жизнь их видел человек 10, тут явная ошибка в данных и наоборот, в статистике написано что 90% населения европеоиды и решают, что ну да, вполне соответствует моему опыту. все верно. Так что проверка данных - это нормальный процесс. а не вопрос доверия к ним.
Тоже самое и с корреляциями, в науке давно научились с ними работать, а специалисты по данным, вроде как, до сих пор удивляются. Любые корреляции данных в рамках эксперимента. которые не связаны с гипотезой могут быть только восприняты как предмет для отдельного исследования, но не как материал для вывода, потому что при сборе большого количества метрик очень высокая вероятность, что две метрики будут вести себя случайно похоже. Верно и обратное - если вы не видите прямой связи между метриками. это не значит. что ее нет, вопрос в интерпретациях.
Вот вам, например, интересные данные, которые согласно вашей статье нам нельзя нести заказчику - средняя продолжительность жизни вич-положительных превышает среднюю продолжительность жизни здоровых по состоянию на 2016 год. При этом процент хронических заболеваний у них выше и манифестация раньше. Согласитесь. с точки здравого смысла - это же бред. Ну и странная корреляция между высокой частотой хронических заболеваний и высокой длительностью жизни, что казалось бы должно быть наоборот. Но если мы как-раз таки займемся вопрос интерпретации и сбора данных, то выясним. что вич-положительные обращаются к врачам гораздо чаще и охотнее, чем их "здоровые" соседи, а значит получают помощь раньше, но и выявляют проблемы у них чаще и раньше, за счет более аккуратного слежения за здоровьем и регулярным медицинским процедурам, живут дольше.
Так что доверять данным можно и нужно, если вы качественно провели их проверку и это не вопрос софт-скиллов, это вполне себе хард-скилл исследовательская задача.
Вообще обычно не меняются, так как эти стрелки обозначали направление перемотки пленки, но с учетом. что перевернули шкалу прогресса трека, это может ввести в заблуждение. Вообще. как я думал в случае с музыкой эту шкалу тоже не переворачивают.
UPD: Проверил, ради интереса, Apple music со мной согласен. Шкала громкости у них инвертирована, шкала прогресса песни нет, и соответственно кнопки означают направление прокрутки правильное.
EPC - хорошая нотификация, ее плюс, что она максимально понятна и в принципе ее можно спокойно показывать и не техническим специалистам. Главное не забывать, что она не просто так называет Event-driven в этом ее принцип, чередование события и функции реакции на это событие которое порождает следующее событие.
Sequence диаграмма из UML - однозначно обязательна к изучению и использованию. Самая нужная и удобная диаграмма взаимодействия между системами. Остальные UML по желанию, есть полезные, но эту прям в первую очередь.
С4 - для описания архитектуры системы. Тоже достаточно простая и наглядная нотация. ПО сравнению с конкурентами не выглядит как пережиток конструкторских бюро из 70-х. )
Это по крайней мер то, что я чаще всего использую, а так по необходимости еще много всего есть, главное не забывать, что это все инструменты, а инструмент надо подбирать под задачи. серебрнную пулю так и не изобрели(
Но в свою защиту могу сказать, стандартизация это очень хорошо, но все-таки главное, чтобы разработчику была однозначно понятна задача.
Абсолютно верно, именно по этому и важна стандартизация, она позволяет нам быть уверенным в том, что Я, заказчик и разработчик понимаем эту диаграмму одинаково, потому что элементы диаграммы для нас значат одно и тоже, и нам не надо предварительно проговаривать ее целиком. Из опыта могу сказать, что не всегда то, что нам кажется однозначно понятным так же однозначно понятно другим и возникают абсолютно неожиданные интерпретации. Стандарты нотфикац3ии позволяют избежать таких ситуаций. По этому я часто встречал даже на курсах такое мнение, что не важны стандарты, главное что бы было понятно, и когда это правило в устоявшемся коллективе - это имеет место быть, когда такое начинают пропагандировать на уровне курсов - за такое надо бить палками ,потому что это просто упрощение ради доступности, что бы больше людей прогнать через курс и состричь больше бабла. А я с таким, к сожалению, сталкивался.
Так что для собственного роста лучше гнать от себя такие соблазнительные мысли и следовать золотому правилу: " Прежде чем научиться делать плохо - научитесь делать хорошо".
Но ведь это не EPC... И это в общем-то отражает всю суть происходящего. Заметно острая нехватка теоретической базы и фундамента. Это общая проблема большинства тех, кто пришел в ИТ и аналитику со стороны "из слесарей" (ни в коем случае не хочу обидеть слесарей, я со своими руками из области ниже поясницы вообще восхищаюсь людьми, которые могут что-то делать своими руками, просто это буквально название вашей статьи). Что бы корректно описать процесс и задачу это должно быть наглядно. а главное однозначно, а для этого необходимо мало-мальски придерживаться нотации, а не просто использовать похожие значки.
Понятно. =) Просто из статьи это непонятно и сразу настраивает на скептическое отношение к дальнейшему тексту, раз уже в начале идет смешение теплого с мягким. )
За все хорошее, против всего плохого. При чем тут системный анализ и аудит ИБ не понятно и статья это никак не объясняет. Статья в принципе ничего не объясняет, кроме общих фраз из любой брошюри любой компании, занимающейся ИБ.
Согласовывают, но в том виде, который им удобен и понятен. Проще говоря они диктуют форму. а не мы. Из-за этого зачастую приходится дублировать документацию. И это не единичный случай, большинство крупных заказчиков так работают.
1. Заказчиков все еще нужно заставлять читать требования и читать им придется, водя пальчиком по диаграммам, иногда возвращаясь к развилкам, вместо зачастую более привычного им текста и списков.
Первый же минус ставит крест на подходе процентах в 70-80 случаев, а если речь идет о крупных заказчиках, то в 99%. потому что заставить заказчика что-то сделать почти нереально, у многих есть свои процессы, свои документы и шаблоны и свои подходы и ни один заказчик не будет подстраиваться под ваши процессы, если вы не безальтернативный монополист.
Очень интересно будет почитать. Потому что с ходу это не очень очевидно, тем более в части достаточности этого требования. То есть означает ли планарность графа отсутствие в нем дублирования?
Это скорее проверка на прочность всех систем фильтров и защиты. У ботов нет морали и принципов, а значит прежде чем доверить что-то серьезнее, чем болтовня в чате им их надо привить. Те самые пресловутые 3 правила робототехники, что бы в какой-то момент ИИ ответственный за производственный процесс не посчитал, что продолжение работы конвейера, например, математически эффективнее вашей жизни. И многие хотят убедиться, что роботам не так то просто будет эти правила нарушить. Но пока, как мы видим, это достаточно просто.
Я как-то проходил собеседование в один банк, и там правильным ответом было именно то, что вы озвучили. А точнее их комментарий, что если проблему можно быстро решить дополнительным железом - это их устраивает. В некоторых случаях "залить пожар деньгами" для некоторых компаний реально проще и выгоднее, чем потерять время на разборки. Разбираться будут потом, когда вокруг перестанет все гореть.
Ну я так же могу сказать, что 99% желчи со стороны Миши - это нежелание шевелиться. Зачем, если и в болоте уютненько. ЕСли докапываться до каждой мелочи и требовать идеально выровненных ячеек в таблице, то да, 5 -10-15 лет TTM не предел. А если просто взять и сделать. Пусть не идеально и с косяками на старте, но для того и придумали все эти ваши аджайлы, то жизнеспособный продукт можно выпустить уже через полгода-год. Не все же тут ядерные реакторы запускают и обеспечивают работу международных бирж, какие-то баги мир переживет.
Чаще всего люди просто не замечают, как обижают людей. Я могу по себе сказать, еще года 3-4 назад я сам был таким Мишей. Просто капец каким неприятным типом из которого желчь и токсичность лилась просто через край. Скажу честно, спасибо некоторым людям, благодаря которым я это стал замечать и начал работать над собой. До сих пор иногда проскакивает, но все же я на верном пути. ) Так вот к чему это я, тогда я тоже не считал, что что-то делаю не так, все ради компании, проекта и этих несмышленышей, кто же их еще научит как правильно, а то ведь сами не заметят, как весь проект завалиться. А они еще и обижаются что-то, вот ведь неженки какие, все им "токсичность и пассивная агрессия".
Более чем. Без технической базы и насмотренности будет тяжело
Мне кажется вы не правильно представляете себе обязанности аналитика. Как вы себе представляете "Просто соединить знания"? Нельзя просто взять и вписать слова одного и другого специалиста в один документ. С этим они бы и сами справились в каком-нибудь гугл-доке или конфлюенсе. Что бы "соединить знания" надо самому обладать этими знаниями, может чуть в меньшей степени чем исходный специалист, но куда шире по областям. Но это если бы задача была только в этом. Но вообще от аналитика требуется выработка и принятие оптимальных решений, и одинаково эффективно принимать и технические и бизнес-решения по процессу одному человеку может быть весьма не просто.
Может конечно в вашей компании позицию аналитика редуцировали до говорящего попугая, но вообще это не так. =)
Проблема в том. что это скорее баг. а не фича. Я почти не видел таких универсальных специалистов, есть либо сильна БА который слабо разбираются в технике, либо сильные СА, которые в БА разбираются больше интуитивно. И это в целом нормально, потому что обе сферы огромные и стать хорошим специалистом в обеих сферах почти нереально. При этом на мой взгляд не надо нормализовывать эту ситуацию подобными оправдывающими статьями.
"В заключение, несмотря на разделение на фронт-энд разработчика и бэк-енд разработчика, настоящий профессионал в сфере B2B должен обладать навыками обеих профессий и уметь сочетать их в рамках продукта, с которым он работает. Фулл-стек разработчик, обладающий глубоким пониманием фронта и бэка, является ценным активом для организации." Казалось бы одно и тоже, но почему-то от всех разработчиков не требуют быть фулл-стек. Наверно потому что глубокая экспертиза в чем-то не менее ценна чем поверхностное знание по многим областям. А то, что организации куда выгоднее и ценее платить одному спецйиалисту одну зарплату за работу двух специалистов - тут никаких сомнений.
С каких пор умение работать с данными стало софт-скиллом? Раньше эти навыки были обязательны для любого, кто занимался наукой от физики до психологии, а теперь выделили в отдельную профессию.
Первый пункт про недоверие к данным - это вообще за гранью. Как можно не доверять данным с которыми ты работаешь? в чем тогда смысл такой работы? Вопрос не про доверие, тут вопрос про умение их интерпретировать и работать с ними, при чем работать и на этапе их сборки. Вы привели примеры данных, которые на уровне здравого смысла некорректны. а что делать с данными, которые не так очевидны? А что делать с данными, которые корректны, но контринтуитивны? Тут надо задаваться всегда вопросом о методике сбора данных и правдивости источника, но чего точно не должен делать профессионал, так это опираться на личный опыт и "здравый смысл". Например я смотрю на статистику, где написано. что в мире 10% населения чернокожие и опираясь на личный опыт могу сказать. что ну это же бред, я за всю жизнь их видел человек 10, тут явная ошибка в данных и наоборот, в статистике написано что 90% населения европеоиды и решают, что ну да, вполне соответствует моему опыту. все верно. Так что проверка данных - это нормальный процесс. а не вопрос доверия к ним.
Тоже самое и с корреляциями, в науке давно научились с ними работать, а специалисты по данным, вроде как, до сих пор удивляются. Любые корреляции данных в рамках эксперимента. которые не связаны с гипотезой могут быть только восприняты как предмет для отдельного исследования, но не как материал для вывода, потому что при сборе большого количества метрик очень высокая вероятность, что две метрики будут вести себя случайно похоже. Верно и обратное - если вы не видите прямой связи между метриками. это не значит. что ее нет, вопрос в интерпретациях.
Вот вам, например, интересные данные, которые согласно вашей статье нам нельзя нести заказчику - средняя продолжительность жизни вич-положительных превышает среднюю продолжительность жизни здоровых по состоянию на 2016 год. При этом процент хронических заболеваний у них выше и манифестация раньше. Согласитесь. с точки здравого смысла - это же бред. Ну и странная корреляция между высокой частотой хронических заболеваний и высокой длительностью жизни, что казалось бы должно быть наоборот. Но если мы как-раз таки займемся вопрос интерпретации и сбора данных, то выясним. что вич-положительные обращаются к врачам гораздо чаще и охотнее, чем их "здоровые" соседи, а значит получают помощь раньше, но и выявляют проблемы у них чаще и раньше, за счет более аккуратного слежения за здоровьем и регулярным медицинским процедурам, живут дольше.
Так что доверять данным можно и нужно, если вы качественно провели их проверку и это не вопрос софт-скиллов, это вполне себе хард-скилл исследовательская задача.
Вообще обычно не меняются, так как эти стрелки обозначали направление перемотки пленки, но с учетом. что перевернули шкалу прогресса трека, это может ввести в заблуждение. Вообще. как я думал в случае с музыкой эту шкалу тоже не переворачивают.
UPD: Проверил, ради интереса, Apple music со мной согласен. Шкала громкости у них инвертирована, шкала прогресса песни нет, и соответственно кнопки означают направление прокрутки правильное.
EPC - хорошая нотификация, ее плюс, что она максимально понятна и в принципе ее можно спокойно показывать и не техническим специалистам. Главное не забывать, что она не просто так называет Event-driven в этом ее принцип, чередование события и функции реакции на это событие которое порождает следующее событие.
Sequence диаграмма из UML - однозначно обязательна к изучению и использованию. Самая нужная и удобная диаграмма взаимодействия между системами. Остальные UML по желанию, есть полезные, но эту прям в первую очередь.
С4 - для описания архитектуры системы. Тоже достаточно простая и наглядная нотация. ПО сравнению с конкурентами не выглядит как пережиток конструкторских бюро из 70-х. )
Это по крайней мер то, что я чаще всего использую, а так по необходимости еще много всего есть, главное не забывать, что это все инструменты, а инструмент надо подбирать под задачи. серебрнную пулю так и не изобрели(
Абсолютно верно, именно по этому и важна стандартизация, она позволяет нам быть уверенным в том, что Я, заказчик и разработчик понимаем эту диаграмму одинаково, потому что элементы диаграммы для нас значат одно и тоже, и нам не надо предварительно проговаривать ее целиком. Из опыта могу сказать, что не всегда то, что нам кажется однозначно понятным так же однозначно понятно другим и возникают абсолютно неожиданные интерпретации. Стандарты нотфикац3ии позволяют избежать таких ситуаций. По этому я часто встречал даже на курсах такое мнение, что не важны стандарты, главное что бы было понятно, и когда это правило в устоявшемся коллективе - это имеет место быть, когда такое начинают пропагандировать на уровне курсов - за такое надо бить палками ,потому что это просто упрощение ради доступности, что бы больше людей прогнать через курс и состричь больше бабла. А я с таким, к сожалению, сталкивался.
Так что для собственного роста лучше гнать от себя такие соблазнительные мысли и следовать золотому правилу: " Прежде чем научиться делать плохо - научитесь делать хорошо".
Но ведь это не EPC... И это в общем-то отражает всю суть происходящего. Заметно острая нехватка теоретической базы и фундамента. Это общая проблема большинства тех, кто пришел в ИТ и аналитику со стороны "из слесарей" (ни в коем случае не хочу обидеть слесарей, я со своими руками из области ниже поясницы вообще восхищаюсь людьми, которые могут что-то делать своими руками, просто это буквально название вашей статьи). Что бы корректно описать процесс и задачу это должно быть наглядно. а главное однозначно, а для этого необходимо мало-мальски придерживаться нотации, а не просто использовать похожие значки.
Понятно. =) Просто из статьи это непонятно и сразу настраивает на скептическое отношение к дальнейшему тексту, раз уже в начале идет смешение теплого с мягким. )
Видимо после статей вы все таки не до конца разобрались сравнивая отвертку со слоном.
За все хорошее, против всего плохого. При чем тут системный анализ и аудит ИБ не понятно и статья это никак не объясняет. Статья в принципе ничего не объясняет, кроме общих фраз из любой брошюри любой компании, занимающейся ИБ.
Согласовывают, но в том виде, который им удобен и понятен. Проще говоря они диктуют форму. а не мы. Из-за этого зачастую приходится дублировать документацию. И это не единичный случай, большинство крупных заказчиков так работают.
Первый же минус ставит крест на подходе процентах в 70-80 случаев, а если речь идет о крупных заказчиках, то в 99%. потому что заставить заказчика что-то сделать почти нереально, у многих есть свои процессы, свои документы и шаблоны и свои подходы и ни один заказчик не будет подстраиваться под ваши процессы, если вы не безальтернативный монополист.
Очень интересно будет почитать. Потому что с ходу это не очень очевидно, тем более в части достаточности этого требования. То есть означает ли планарность графа отсутствие в нем дублирования?
Это скорее проверка на прочность всех систем фильтров и защиты. У ботов нет морали и принципов, а значит прежде чем доверить что-то серьезнее, чем болтовня в чате им их надо привить. Те самые пресловутые 3 правила робототехники, что бы в какой-то момент ИИ ответственный за производственный процесс не посчитал, что продолжение работы конвейера, например, математически эффективнее вашей жизни. И многие хотят убедиться, что роботам не так то просто будет эти правила нарушить. Но пока, как мы видим, это достаточно просто.
Ага, только их назвали «тихие группы безукоризненно незаметных людей»
Я как-то проходил собеседование в один банк, и там правильным ответом было именно то, что вы озвучили. А точнее их комментарий, что если проблему можно быстро решить дополнительным железом - это их устраивает. В некоторых случаях "залить пожар деньгами" для некоторых компаний реально проще и выгоднее, чем потерять время на разборки. Разбираться будут потом, когда вокруг перестанет все гореть.
Ну я так же могу сказать, что 99% желчи со стороны Миши - это нежелание шевелиться. Зачем, если и в болоте уютненько. ЕСли докапываться до каждой мелочи и требовать идеально выровненных ячеек в таблице, то да, 5 -10-15 лет TTM не предел. А если просто взять и сделать. Пусть не идеально и с косяками на старте, но для того и придумали все эти ваши аджайлы, то жизнеспособный продукт можно выпустить уже через полгода-год. Не все же тут ядерные реакторы запускают и обеспечивают работу международных бирж, какие-то баги мир переживет.
Чаще всего люди просто не замечают, как обижают людей. Я могу по себе сказать, еще года 3-4 назад я сам был таким Мишей. Просто капец каким неприятным типом из которого желчь и токсичность лилась просто через край. Скажу честно, спасибо некоторым людям, благодаря которым я это стал замечать и начал работать над собой. До сих пор иногда проскакивает, но все же я на верном пути. ) Так вот к чему это я, тогда я тоже не считал, что что-то делаю не так, все ради компании, проекта и этих несмышленышей, кто же их еще научит как правильно, а то ведь сами не заметят, как весь проект завалиться. А они еще и обижаются что-то, вот ведь неженки какие, все им "токсичность и пассивная агрессия".