Смутило, что статья названа "Системный аналитик и искусственный интеллект: друзья или враги?" , а примерно с середины текста разговор пошел о карьере бизнес‑аналитика . Опечатка?
Ощущение, что прочитала текстовое изложение известных диаграмм вроде матрицы влияние-интерес, причем самих диаграмм в тексте нет, зато есть адаптация в табличном формате. Было бы интересно понять преимущество такого подхода по сравнения с хрестоматийным
Коллеги уже много комментировали и остается только присоединиться. Откуда это деление на "чистых" и "не чистых"? Даже если пренебречь этической и содержательной стороной вопроса, то с лингвистической точки зрения совсем забавно. Если слитно написать "нечистый", то можно заменить словом "леший" )))
И почему в тегах и бизнес-анализ и бизнес-аналитика? Какая из этих разных дисциплин стала в итоге предметом статьи?
Не думаю, что не нужно тягаться амбициями и знаниями, в каждой сфере они свои. Результат такой замены БА системным аналитиком - это обычно либо честно записанные слова бизнеса, который напридумывал себе функций, либо имеем договоренности, подогнанные под реализацию... Для небольших типовых задач это прокатывает, а бывает, что лучше нанять БА
Мало я припомню проф. тусовок, где рано или поздно не обсуждалось бы "кто круче" и заканчивается это обычно ничем. Наверное, это кому-то важно и нужно...
В реальности все зависит от того, что специалист умеет делать. Одинаково грустно видеть человека, который умеет только кое-как записать чужие мысли, независимо от того как называется его роль... Моя мысль была в том, что хорошо бы ориентироваться не на название роли и веяние времени, а на ваши навыки и интересы.
Все правда. Дефицит кадров в сочетании с уходящей привычкой читать большие тексты приводит к редким перлам в документации. Коротко не получается, если нет насмотренности на хорошие примеры и системности в мышлении.
С другой стороны аналитики жалуются, что разработчики не всегда готовы читать описания. Даже приличные описания. Мне еще в роли разработчика повезло видеть ТЗ на 300 страниц (распечатанное и переплетенное в увесистый том), которое когда-то люди прочитывали. Сейчас такое невозможно совсем, никто не читает большие литературные форматы.
Недавно в одном из профессиональных чатиков, коллега утверждал, что нет никаких СА и БА, а есть одна общая роль проектировщика. Основным аргументом было "работаю с 78го года и знаю точно". Были времена, когда были только БА, а СА как отдельная роль позже появились. Есть разные мнения относительно перспектив разных аналитиков в индустрии, некоторые довольно пессимистичные и звучат примерно так же как вы и сформулировали... Если интересно много общаться, изучать как люди работают, искать "узкие горлышки" почему не быть БА? Времена и договоренности в командах меняются, советую стремиться туда, где у вас есть талант и интерес.
Мнения о "входе" и правда разные. Я оказалась аналитиком примерно тогда же, когда эта роль появилась в ИТ, в середине нулевых. Перешла из роли лидера группы тестирования, а до того разработчиком была... Хотела больше общаться с людьми, научиться быстро понимать их потребности и превращать в хорошие продукты. Сейчас это звучит забавно, но в те времена для перехода в БА были важны знания в ИТ+иностранные языки.
Согласна, что такое бывает. При этом у меня нет ощущения, что пользователи обязаны быть способными дать развернутый технологичный ответ. Например, я не смогу ответить стоматологу, если он начнет меня спрашивать каким материалом заменить пломбу и какой там был до этого? а на вопрос, что я делаю, если зуб болит я отвечу - записываюсь к врачу... такой вот незрелый пациент из меня. Но неужели совсем не нужно моим мнением интересоваться?
При любом ответе (даже если говорят "да нет у нас проблемы") не достаточно одного только интервью, чтобы сделать выводы - нужно поговорить с ИТ-поддержкой, понаблюдать за работой пользователя (если покажут), посмотреть логи систем (если есть), в регламенты заглянуть, данные поискать.... Но вы наверняка это все знаете...
Матрица компетенций БА все же шире, чем абстрактные пункты SDLC, Стейкхолдеры, Работа с требованиями и Эмоциональный интеллект. Одна только "Работа с требованиями" состоит как минимум из выявление, анализ, документирование, управление...
Было бы интереснее понять, почему именно эти публикации считаете ценными, чем они особенно важны для БА? Почему специалисту по оптимизации важно прочесть книгу "Разработка требований к программному обеспечению"? Книга отличная, но бизнес-анализ не всегда про ПО...
Мне не хватило рассказа еще и о том как не просто предоставить открытость, инновации и автономность, но и внедрить в коллективе умение этим пользоваться. В реальности, не каждый к этому готов, ведь 1) автономность означает - отвечаешь за результат именно ты, а не руководитель, 2) открытость означает, что и разработчик открывает карты и тратит время на обмен знаниями, чтение документов и хождение по встречам 3) инновации означают готовность постоянного развития компетенций (здесь проще и понятнее, но все ли готовы?)...
На мой взгляд, помимо перечисленного в статье важны понятные цели задач. Никто не любит работать в стол или бесконечно перекладывать одно и то же с монолита на микросервисы ) Когда делаются вещи для людей с понятными целями, то и мотивация к работе повышается.
Загрустила от нераскрытого вопроса в заголовке. Для меня сейчас вопрос выглядит так: "Команда не готова читать больше половины страницы текста", с этой точки зрения нет обличий между первым и вторым подходом в статье. Согласна с теми, кто пишет, что хорошо бы создавать документацию после разработки как справочный материал и гайды для пользователей, а для постановки задачи использовать что-то еще...
Смутило, что статья названа "Системный аналитик и искусственный интеллект: друзья или враги?" , а примерно с середины текста разговор пошел о карьере бизнес‑аналитика . Опечатка?
Спасибо за такую детальную статью с компетентным разбором вопроса. Чувствуется долгая работа над наболевшим вопросом.
Ощущение, что прочитала текстовое изложение известных диаграмм вроде матрицы влияние-интерес, причем самих диаграмм в тексте нет, зато есть адаптация в табличном формате. Было бы интересно понять преимущество такого подхода по сравнения с хрестоматийным
Коллеги уже много комментировали и остается только присоединиться. Откуда это деление на "чистых" и "не чистых"? Даже если пренебречь этической и содержательной стороной вопроса, то с лингвистической точки зрения совсем забавно. Если слитно написать "нечистый", то можно заменить словом "леший" )))
И почему в тегах и бизнес-анализ и бизнес-аналитика? Какая из этих разных дисциплин стала в итоге предметом статьи?
Не думаю, что не нужно тягаться амбициями и знаниями, в каждой сфере они свои. Результат такой замены БА системным аналитиком - это обычно либо честно записанные слова бизнеса, который напридумывал себе функций, либо имеем договоренности, подогнанные под реализацию... Для небольших типовых задач это прокатывает, а бывает, что лучше нанять БА
Разве плохо кого-то "улыбнуть"? :)
О терминах пользователя уже написала тут https://habr.com/ru/articles/771986/. В статье по интервью фокус именно на интервьюерах.
Мало я припомню проф. тусовок, где рано или поздно не обсуждалось бы "кто круче" и заканчивается это обычно ничем. Наверное, это кому-то важно и нужно...
В реальности все зависит от того, что специалист умеет делать. Одинаково грустно видеть человека, который умеет только кое-как записать чужие мысли, независимо от того как называется его роль... Моя мысль была в том, что хорошо бы ориентироваться не на название роли и веяние времени, а на ваши навыки и интересы.
Долго думала как ответить и никого не задеть :)
Все правда. Дефицит кадров в сочетании с уходящей привычкой читать большие тексты приводит к редким перлам в документации. Коротко не получается, если нет насмотренности на хорошие примеры и системности в мышлении.
С другой стороны аналитики жалуются, что разработчики не всегда готовы читать описания. Даже приличные описания. Мне еще в роли разработчика повезло видеть ТЗ на 300 страниц (распечатанное и переплетенное в увесистый том), которое когда-то люди прочитывали. Сейчас такое невозможно совсем, никто не читает большие литературные форматы.
Недавно в одном из профессиональных чатиков, коллега утверждал, что нет никаких СА и БА, а есть одна общая роль проектировщика. Основным аргументом было "работаю с 78го года и знаю точно". Были времена, когда были только БА, а СА как отдельная роль позже появились. Есть разные мнения относительно перспектив разных аналитиков в индустрии, некоторые довольно пессимистичные и звучат примерно так же как вы и сформулировали... Если интересно много общаться, изучать как люди работают, искать "узкие горлышки" почему не быть БА? Времена и договоренности в командах меняются, советую стремиться туда, где у вас есть талант и интерес.
Мнения о "входе" и правда разные. Я оказалась аналитиком примерно тогда же, когда эта роль появилась в ИТ, в середине нулевых. Перешла из роли лидера группы тестирования, а до того разработчиком была... Хотела больше общаться с людьми, научиться быстро понимать их потребности и превращать в хорошие продукты. Сейчас это звучит забавно, но в те времена для перехода в БА были важны знания в ИТ+иностранные языки.
Согласна, что такое бывает. При этом у меня нет ощущения, что пользователи обязаны быть способными дать развернутый технологичный ответ. Например, я не смогу ответить стоматологу, если он начнет меня спрашивать каким материалом заменить пломбу и какой там был до этого? а на вопрос, что я делаю, если зуб болит я отвечу - записываюсь к врачу... такой вот незрелый пациент из меня. Но неужели совсем не нужно моим мнением интересоваться?
При любом ответе (даже если говорят "да нет у нас проблемы") не достаточно одного только интервью, чтобы сделать выводы - нужно поговорить с ИТ-поддержкой, понаблюдать за работой пользователя (если покажут), посмотреть логи систем (если есть), в регламенты заглянуть, данные поискать.... Но вы наверняка это все знаете...
Это уже другой тип вопроса - провокационный :)
И правда, очень похоже )
Матрица компетенций БА все же шире, чем абстрактные пункты SDLC, Стейкхолдеры, Работа с требованиями и Эмоциональный интеллект. Одна только "Работа с требованиями" состоит как минимум из выявление, анализ, документирование, управление...
Было бы интереснее понять, почему именно эти публикации считаете ценными, чем они особенно важны для БА? Почему специалисту по оптимизации важно прочесть книгу "Разработка требований к программному обеспечению"? Книга отличная, но бизнес-анализ не всегда про ПО...
Мне не хватило рассказа еще и о том как не просто предоставить открытость, инновации и автономность, но и внедрить в коллективе умение этим пользоваться. В реальности, не каждый к этому готов, ведь 1) автономность означает - отвечаешь за результат именно ты, а не руководитель, 2) открытость означает, что и разработчик открывает карты и тратит время на обмен знаниями, чтение документов и хождение по встречам 3) инновации означают готовность постоянного развития компетенций (здесь проще и понятнее, но все ли готовы?)...
На мой взгляд, помимо перечисленного в статье важны понятные цели задач. Никто не любит работать в стол или бесконечно перекладывать одно и то же с монолита на микросервисы ) Когда делаются вещи для людей с понятными целями, то и мотивация к работе повышается.
Тоже часто его слышу. Канцеляризм, который многим кажется красивым и внушительным :(
Загрустила от нераскрытого вопроса в заголовке. Для меня сейчас вопрос выглядит так: "Команда не готова читать больше половины страницы текста", с этой точки зрения нет обличий между первым и вторым подходом в статье. Согласна с теми, кто пишет, что хорошо бы создавать документацию после разработки как справочный материал и гайды для пользователей, а для постановки задачи использовать что-то еще...
Хотелось бы больше информации о принципе работы этого класса систем. За этим я открывала статью, но нашла только стратегические показатели :(