Комментарии 47
Аналитик это человек который формализует бизнес требования, дополняет бизнес требования не функциональными требованиями (требования к качеству и характеристикам).
А вот всё остальное про чтение кода, чтение логов, просчёт последствий изменений в бэкэнде на фронтэнд, и прочая прочая это не аналитик. Это архитектор если по технической части, UX/UI дизайнер если по видимой части работы программного продукта и прочие люди которые тоже нужны и которые тоже имеют свои участки ответственности.
Аналитик это не тот кто знает всё и может во всё разобраться. Всё про систему на троих знают: владелец продукта, архитектор, админ отвечающий за эксплуатацию (настройка окружения, выкатка, мониторинг текущий метрик, обеспечение стабильного функционирования).
А вот всё остальное про чтение кода, чтение логов, просчёт последствий изменений в бэкэнде на фронтэнд, и прочая прочая это не аналитик. Это архитектор если по технической части, UX/UI дизайнер если по видимой части работы программного продукта и прочие люди которые тоже нужны и которые тоже имеют свои участки ответственности.
Аналитик это не тот кто знает всё и может во всё разобраться. Всё про систему на троих знают: владелец продукта, архитектор, админ отвечающий за эксплуатацию (настройка окружения, выкатка, мониторинг текущий метрик, обеспечение стабильного функционирования).
Согласен, все что в roadmap слева это не про системного аналитика, а про архитектора.
Оббежать всех ЛПР на стороне заказчика, записать их хотелки, хорошо-бы еще под протокол. Перевести все что нужно в use cases, описать деревья требований хоть в requesitPro, сформировать детальные спецификации на каждый модуль, отдать в разработку. Если разработчику требование непонятно — обьяснить/исправить описание на понятное. Если у заказчика новая хотелка — оценить ее взаимовлияние на уже проведенные работы, если цена изменения согласована, провести изменения во всех связанных сущностях.
А вот траблшутинг и прочее с тестированием — это не дело аналитика.
Во всяком случае так было 15 лет назад.
Оббежать всех ЛПР на стороне заказчика, записать их хотелки, хорошо-бы еще под протокол. Перевести все что нужно в use cases, описать деревья требований хоть в requesitPro, сформировать детальные спецификации на каждый модуль, отдать в разработку. Если разработчику требование непонятно — обьяснить/исправить описание на понятное. Если у заказчика новая хотелка — оценить ее взаимовлияние на уже проведенные работы, если цена изменения согласована, провести изменения во всех связанных сущностях.
А вот траблшутинг и прочее с тестированием — это не дело аналитика.
Во всяком случае так было 15 лет назад.
kagarich, возможно, сейчас требования к аналитикам стали выше
Да нет, просто есть компании, которым нужен специалист поддержки, девопс, аналитик, архитектор, тестировщик, дизайнер, UX-проектировщик и техпис, всё это не считая разработчиков и управленцев.
А есть те, которым нужен эникейщик, чтоб умел всё и подешевле. Как умеет — не так уж и важно, всё равно никто не разбирается.
А есть те, которым нужен эникейщик, чтоб умел всё и подешевле. Как умеет — не так уж и важно, всё равно никто не разбирается.
C одно стороны вы правы, аналитик это в первую очередь требования.
С другой, вот приходит заказчик и говорит, хочу видеть на одной странице в браузере всех пользовательзователей филиала (пример кстати реальный хоть и из совершенно другой области).
И вроде нормальное требование, но если вспомнить что пускай в одном филиале может быть 10 тыс пользователей, а также если есть хотя бы елементарное понимание как это все технически работает, то сразу становиться ясно, что веб-страничка с полноценной таблицей на 10000 строк будет безбожно тормозить.
Более того в таком случае не делая круг к девам, можно сразу копать дальше с вопросами, типа «а где и как и вы это будете использовать, как часто и что хотите увидеть», в результате которых подобное требование и вовсе может отпасть.
Вот так приходиться по чуть-чуть, но вникать в вроде бы и «не нужные» вещи как-то код и
логи.
С другой, вот приходит заказчик и говорит, хочу видеть на одной странице в браузере всех пользовательзователей филиала (пример кстати реальный хоть и из совершенно другой области).
И вроде нормальное требование, но если вспомнить что пускай в одном филиале может быть 10 тыс пользователей, а также если есть хотя бы елементарное понимание как это все технически работает, то сразу становиться ясно, что веб-страничка с полноценной таблицей на 10000 строк будет безбожно тормозить.
Более того в таком случае не делая круг к девам, можно сразу копать дальше с вопросами, типа «а где и как и вы это будете использовать, как часто и что хотите увидеть», в результате которых подобное требование и вовсе может отпасть.
Вот так приходиться по чуть-чуть, но вникать в вроде бы и «не нужные» вещи как-то код и
логи.
Все так. Я не утверждаю, что аналитик это машинистка, которая тупо записывает хотелки заказчика. Аналитик, это человек, который имеет широчайший кругозор по всему стеку применяемых технологий, от фронта (HTML, JS, апплеты, флэш и т.п.), до бэкенда (СУБД, access, identity, и т.п.), более того, он понимает в сетях на уровне forest / domain, firewall / ports / protocol. Все это не для багфиксинга, а для корректного сбора и управления требованиями, чтобы на этапе интервьюирования и документирования не говорить/писать откровенную чушь, на ходу управляя хотелками заказчика "… вы знаете, если вот это ваше требование реализовать, то загрузка интерфейса займет более 10 сек, и потребует вот такой-то конфигурации на клиенте, давайте рассмотрим вот такой вариант, он позволит..."
Чтоб понимать, что страничкой с полноценной таблицей на 10000 строк будет невозможно пользоваться, бегать круги к девам не нужно, ИМХО. И вовсе не потому, что будет тормозить…
Увы, слишком много людей привыкло к Excel, и пытается его притянуть куда надо и не надо. Я вот честно не могу понять, как можно работать с таблицей (даже того же екселя), которая по ширине не вмещается в стандартный монитор 20 дюймов.
Однако заказчики такие файлы приносят с завидной регулярностью.
Однако заказчики такие файлы приносят с завидной регулярностью.
Для передачи данных это нормально, для экспорта. Но не просмотра глазками
Так в чистом виде не смотрят, используют фильтры)сортировки и прочую пост. обработку, но проблема в том что формализация этого процесса часто невозможна (либо реализация всех вариантов дороже чем "как есть" в сотни раз).
Когда есть фильтр — к просмотру остаётся куда меньше записей. Когда есть сортировка — вполне работают лимиты пагинации, и тоже к просмотру остаётся небольшой обозримый кусок из начала сортированного списка.
Я до сих пор удивляюсь, почему в огромном количестве средств просмотра таблиц фильтры и сортировка как правило чрезвычайно убогие… Что онлайн, что даже в толстых клиентах ERP-систем…
Я до сих пор удивляюсь, почему в огромном количестве средств просмотра таблиц фильтры и сортировка как правило чрезвычайно убогие… Что онлайн, что даже в толстых клиентах ERP-систем…
Вы наверное меня не совсем поняли, фильтры они в голове, включаются в зависимости от ситуации…
Про пагинацию, ну это вы не про отчётность явно, и не про наборы в сотни тысяч строк после фильтрации и обработки...
Фильтры должны быть в компьютере, достаточно удобными и функциональными, чтоб не держать их в голове и не мотать километровые простыни.
И да, в том числе для отчётов, которые смотрят глазками. А те отчёты, которые глазками не смотрят — те и не смотрят, так что мы сейчас не о них.
И да, в том числе для отчётов, которые смотрят глазками. А те отчёты, которые глазками не смотрят — те и не смотрят, так что мы сейчас не о них.
Я так тоже считаю, но реальность она другая, процессы, правила, алгоритмы — всё меняется и очень быстро, на рынке до сих пор нет "универсального решения" с обозримым горизонтом времени на настройку/доработку, у каждого крупного игрока свои костыли/эксели и "продвинутые пользователи. И дело не в том что "денег не дают", просто формализация не поспевает за изменениями.
В табличках и фильтрах к ним сильно меняться почти нечему.
Но да, на рынке явных массово пригодных решений по-прежнему нет. Я вот и удивляюсь, почему они не востребованы и большинство забивает вовсе либо лепит себе кривые костыли…
Но да, на рынке явных массово пригодных решений по-прежнему нет. Я вот и удивляюсь, почему они не востребованы и большинство забивает вовсе либо лепит себе кривые костыли…
Я вроде уже писал: сделать универсальное решение — написать свой excel :)
Решения есть от крупных вендоров за очень много денег, но проблема в том что чуть шаг влево шаг вправо, они перестают работать как надо, а доработка (если не брать финансовую составляющую) просто не успевает не только за требованиями бизнеса но и за требованиями регулирующих стандартов.
Без архитекторов и дизайнеров никуда, согласна
Однако в масштабах банка архитектора занимаются более глобальными вопросами, нежели анализ влияния изменений на конкретный продукт (систему)
Что касается саппортов — здорово, когда причины багов находятся без участия продуктовых команд. Но не всегда поддержка имеет возможность подгружаться в задачу на уровень, необходимый для ее решения. Так задача возвращается на аналитика
Однако в масштабах банка архитектора занимаются более глобальными вопросами, нежели анализ влияния изменений на конкретный продукт (систему)
Что касается саппортов — здорово, когда причины багов находятся без участия продуктовых команд. Но не всегда поддержка имеет возможность подгружаться в задачу на уровень, необходимый для ее решения. Так задача возвращается на аналитика
Работаю БА/СА в Альфе 3 мес, ничего так, отличная атмосфера!
Имхо, в карте нету технологий по работе с фреймами/мокапами таких как Axure или moqups.com.
Ну а в целом добавляю в закладки «на случай важных переговоров» (достало вечно объяснять человекам одно и то-же)
Имхо, в карте нету технологий по работе с фреймами/мокапами таких как Axure или moqups.com.
Ну а в целом добавляю в закладки «на случай важных переговоров» (достало вечно объяснять человекам одно и то-же)
По идее, аналитик и владелец продукта должны быть одним и тем же лицом
6 лет проработал в IT банка, когда наняли аналитиков работать стало намного сложнее. Вроде как они должны были формализировать требования и описать их ясным языком на практике они их искажали и частично пропускали. Кроме того пришлось их еще и учить, т.к. ничего не знали с начала. В добавок еще аналитики занялись интригами, т.е. не тем чем должны. Т.е. мой опыт работы с ними негативный.
Более бессмысленных сотрудников, чем аналитики в банке, просто нету. После пары лет бессмысленных метаний, я просто продемонстрировал всем их недалекость и запретил им соваться в мою область.
Если речь об анализе внешних факторов, то это лучше сделают соответствующие агенства. Если речь о внутренних бизнес-процессах, то они понимают меньше, чем профильные подразделения. Можно заказать такой анализ опять-таки агентству, но и от этого будет мало толку, только если вы не потенциальный покупатель банка.
В итоге резюме — уволить их к чертям. За счёт экономии усилить профильные отделы.
P.S. Я видел нужных аналитиков — в IT-компании. Но они были полезными, если вырастали туда из внедренцев, тестеров. Видел сотрудников банка, которые сами не зная того, занимаются анализом очень хорошо. Так что против самого процесса анализа я не против.
Если речь об анализе внешних факторов, то это лучше сделают соответствующие агенства. Если речь о внутренних бизнес-процессах, то они понимают меньше, чем профильные подразделения. Можно заказать такой анализ опять-таки агентству, но и от этого будет мало толку, только если вы не потенциальный покупатель банка.
В итоге резюме — уволить их к чертям. За счёт экономии усилить профильные отделы.
P.S. Я видел нужных аналитиков — в IT-компании. Но они были полезными, если вырастали туда из внедренцев, тестеров. Видел сотрудников банка, которые сами не зная того, занимаются анализом очень хорошо. Так что против самого процесса анализа я не против.
Это хорошо если последняя линия поддержки, норовят то и пораньше выставить:) Похоже вы попали на толпу джунов-аналитиков, которых массово набрали как дань моде или в попытке что-то быстро решить. Аналитики, ради аналитики действительно бесполезны, а эту роль может выполнять и нередко выполняют люди с другой должностью на визитке. Для эффективной работы аналитику, кроме непосредственно хард-скиллов аналитика нужно и понимание предметной области. В некоторых непростых доменах обучение довольно длительное, особенно, когда оно не выстроено как система. В таких случаях толковые люди, которые давно в этой организации имеют неоспоримое преимущество и дадут фору большинству аналитиков.
nastyapff Можно немного дегтя в бочку мёда?
Все же системным аналитикам, как правильно заметил ваш знакомый бэкэнд-разработчик, и тестировать приходится потому баги буквально режут глаза :)
Вы иллюстрацию озаглавили и в тексте анонсировали как дорожную карту, но плана в ней нет. Дорожная карта подразумевает все же план (последовательность) и сроки, видимо в данном случае изучения технологий, понятий и получения прочих необходимых знаний.
Так же понятия в иллюстрации местами весьма странно сгруппированы, требуется систематизация и уточнение формулировок. В частности вызывает недоумение следующее:
ODBC/JDBC as Database
Содержание ветки Protocols, протоколы бывают разные, похоже просто везде где есть слово «протокол» сюда отнесли. Надеюсь «протоколы совещаний» не к этой ветке относятся? :) Thrift (если вы имели ввиду Apache Thrift) Все же IDL для RPC. Кстати, где RPC? :)
IDL — Тоже странная подборка. Наверное, вы имели ввиду Interface Description Languages (Definition это про другое), тогда туда надо вписать много чего (неужно в А-Банке никак REST не описывают), но вычеркнуть XML, HTML, BPEL (ниже у вас есть WSDL, который в этом подходе IDL), JSON заменить на JSON-WSP.
Имхо, результат работы аналитика должен прояснять картину мира в отдельно взятой области, а не замыливать её. В части Roadmap Exponent
прав, такой результат деятельности аналитика только затруднит работу :)
Увидит разработчик перечисление архитектур: SOA, MSA, client-server, REST и у него(ё) начнет скрипеть мозг :)
nastyapff Можно немного дегтя в бочку мёда?
Все же системным аналитикам, как правильно заметил ваш знакомый бэкэнд-разработчик, и тестировать приходится потому баги буквально режут глаза :)
Вы иллюстрацию озаглавили и в тексте анонсировали как дорожную карту, но плана в ней нет. Дорожная карта подразумевает все же план (последовательность) и сроки, видимо в данном случае изучения технологий, понятий и получения прочих необходимых знаний.
Так же понятия в иллюстрации местами весьма странно сгруппированы, требуется систематизация и уточнение формулировок. В частности вызывает недоумение следующее:
ODBC/JDBC as Database
Содержание ветки Protocols, протоколы бывают разные, похоже просто везде где есть слово «протокол» сюда отнесли. Надеюсь «протоколы совещаний» не к этой ветке относятся? :) Thrift (если вы имели ввиду Apache Thrift) Все же IDL для RPC. Кстати, где RPC? :)
IDL — Тоже странная подборка. Наверное, вы имели ввиду Interface Description Languages (Definition это про другое), тогда туда надо вписать много чего (неужно в А-Банке никак REST не описывают), но вычеркнуть XML, HTML, BPEL (ниже у вас есть WSDL, который в этом подходе IDL), JSON заменить на JSON-WSP.
Имхо, результат работы аналитика должен прояснять картину мира в отдельно взятой области, а не замыливать её. В части Roadmap Exponent
прав, такой результат деятельности аналитика только затруднит работу :)
Увидит разработчик перечисление архитектур: SOA, MSA, client-server, REST и у него(ё) начнет скрипеть мозг :)
astralNord похоже, с «дорожной картой» тут сложности перевода) целью было не предложить конкретный план, а скорее изобразить направления для развития. Поэтому ни конкретики, ни сроков тут нет
Насчет архитектуры не согласна. Во-первых, мидл-разработчику эти слова должны быть как родные. А что касается аналитика, ну как он может описать решение по интеграции, не зная даже, как общаются клиент и сервер
Насчет архитектуры не согласна. Во-первых, мидл-разработчику эти слова должны быть как родные. А что касается аналитика, ну как он может описать решение по интеграции, не зная даже, как общаются клиент и сервер
1. Причём тут сложности перевода? Вы в статье использовали и русскоязычный и англоязычный термин, в обоих языках это план, долгосрочный и очень укрупнённый. Планы бывают с разным горизонтом и разной степенью детальности.
Если вы хотели просто накидать перечень терминов, технологий, понятий, знаний, навыков и умений, которые по вашему мнению полезно знать системному аналитику, то так и пишите «перечень/список… », а не Roadmap. Точность формулировок — это один из важнейших хард-скилов аналитика, ведь люди с разным опытом и знаниями выдаваемые вами тексты/документы должны как можно однозначнее понимать. Растекаться водой по древу — это к маркетологам, а не аналитикам.
2. Так в том то и дело, что для разработчика они обычно родные, потому и такое перечисление вызовет недоумение, как минимум наличием в этом списке client-server (остальные перечисленные тоже client-server), так и то, что вы затронули только один из многих аспектов проектных решений, совокупность которых и складывается в архитектуру.
Это верно, но раз уж начинаете термины употреблять, лучше знать, что они означают.
Если вы хотели просто накидать перечень терминов, технологий, понятий, знаний, навыков и умений, которые по вашему мнению полезно знать системному аналитику, то так и пишите «перечень/список… », а не Roadmap. Точность формулировок — это один из важнейших хард-скилов аналитика, ведь люди с разным опытом и знаниями выдаваемые вами тексты/документы должны как можно однозначнее понимать. Растекаться водой по древу — это к маркетологам, а не аналитикам.
2. Так в том то и дело, что для разработчика они обычно родные, потому и такое перечисление вызовет недоумение, как минимум наличием в этом списке client-server (остальные перечисленные тоже client-server), так и то, что вы затронули только один из многих аспектов проектных решений, совокупность которых и складывается в архитектуру.
А что касается аналитика, ну как он может описать решение по интеграции, не зная даже, как общаются клиент и сервер
Это верно, но раз уж начинаете термины употреблять, лучше знать, что они означают.
"В итоге резюме — уволить их к чертям. За счёт экономии усилить профильные отделы."
Но по сути же теми же аналитиками :)
А так бывают ситуации когда задача пройдя все тернии процесса согласования и анализа в итоге от разработчика возвращается тебе же с просьбой таки объяснить, "поделиться скриптами"… (А то и заказчик исполнителем становится, но это конечно исключения).
В идеальном мире — аналитик только про требования. В реальности же (системный аналитик в ИТ крупного ретейлера):
- бизнес-анализ, помощь БА
- подготовка требований
- разработка архитектуры
- тестирование изменений
- последняя линия техподдержки
- приоритезация и планирование изменений продукта (совместно с заказчиком)
- организация внедрения изменений
- управление проектом (когда изменения масштабные)
Согласен полностью
Разработка архитектуры — задача архитектора (как должно быть ясно из названия). Это совершенно другая специализация. Талантливый человек может, конечно, охватить обе, но для эффективного использования ресурсов он должен заниматься чем-то одним.
@lobomic, в чем вы видите отличия в специализации?
обычно в архитектора и вырастаю из аналитиков (если, конечно, вы имели ввиду не архитектора ПО)
обычно в архитектора и вырастаю из аналитиков (если, конечно, вы имели ввиду не архитектора ПО)
Я, конечно же, имел в виду архитектора ПО. Кроме него я знаю только архитектора данных, но он, по-моему, занимается более глобальными вопросами, чем отдельное приложение. В некоторых фирмах архитектором ещё называют «технолога», который выбирает технологии для приложения. Это тоже, в общем-то, развитие разработчика. А какой же архитектор может вырасти из аналитика?
А какой же архитектор может вырасти из аналитика?
Собственно, системный архитектор. Тот, кто способен оркестрировать развитие систем на уровне их взаимодействия. Подробнее тут en.wikipedia.org/wiki/Systems_architect
не, далеко не последняя линия техподдержки.
Да трудно тут явно сказать. Уровень и зона ответсвенности аналитика отличается не то, что в разных компаниях, а и в рамках одной компании или более того команды. Пожалуй, аналитик самая размытая специальность на нашем рынке. По сути он задействован на всех этапах работы над проектом/продуктом, как до запуска, так и после.
Чем меньше компания, тем больше обязанностей на аналитике: спроектировать архитектуру решения, выгрузить какие либо данные для отчетности, разобраться с дефектом, помочь тестированию, уладить конфликт разработчиков разных платформ.
Если же говорить про большие компании, то там с этим попроще, потому что народу гораздо больше. В некоторых банках аналитики пишут документацию, отдают ее архитекторам или еще кому нибудь(всевозможные тех советы), где она после согласования передается в разработку. Больше аналитик с описанной им функциональностью не сталкивается и занимается новым документом. Постепенно от этого подхода уходят, поднимая флаги разнообразных agile, однако большинство забывают, что при таком подходе нужны еще и компетентные управленцы в составе этих команд. Этих людей можно назвать, что техническими менеджерами, что архитекторами. А таких людей почти нет, потому что потребности в них особо и не было. Часто менеджеры умеют работать с бизнес требованиями в лучшем случае и предоставлением некой формальной отчетности по стадии проекта. Самое тяжелое же бремя ложиться на аналитиков, потому что резко появилась необходимость работы с требованиями/поддержкой/аналитикой/планированием 24x7, а для этого необходимо довольно сильно погружаться в весь проект и около него, что не любят делать менеджеры (я лишь должен требовать от команды), программисты (дайте мне правильно поставленную задачу и отстаньте от меня со своими постоянными встречами). Рынок же по сути не был готов поставлять специалистов, что заметно по дефициту этих «эникейщиков», которые делают описанные на диаграмме из статьи вещи, на рынке.
Чем меньше компания, тем больше обязанностей на аналитике: спроектировать архитектуру решения, выгрузить какие либо данные для отчетности, разобраться с дефектом, помочь тестированию, уладить конфликт разработчиков разных платформ.
Если же говорить про большие компании, то там с этим попроще, потому что народу гораздо больше. В некоторых банках аналитики пишут документацию, отдают ее архитекторам или еще кому нибудь(всевозможные тех советы), где она после согласования передается в разработку. Больше аналитик с описанной им функциональностью не сталкивается и занимается новым документом. Постепенно от этого подхода уходят, поднимая флаги разнообразных agile, однако большинство забывают, что при таком подходе нужны еще и компетентные управленцы в составе этих команд. Этих людей можно назвать, что техническими менеджерами, что архитекторами. А таких людей почти нет, потому что потребности в них особо и не было. Часто менеджеры умеют работать с бизнес требованиями в лучшем случае и предоставлением некой формальной отчетности по стадии проекта. Самое тяжелое же бремя ложиться на аналитиков, потому что резко появилась необходимость работы с требованиями/поддержкой/аналитикой/планированием 24x7, а для этого необходимо довольно сильно погружаться в весь проект и около него, что не любят делать менеджеры (я лишь должен требовать от команды), программисты (дайте мне правильно поставленную задачу и отстаньте от меня со своими постоянными встречами). Рынок же по сути не был готов поставлять специалистов, что заметно по дефициту этих «эникейщиков», которые делают описанные на диаграмме из статьи вещи, на рынке.
системный — указывает на то, с чем работают — системы.
И, также, на то как работают (должны работать) — используя системный подход — моделируя все в виде систем (конструкций из елементов и их связей).
исходя из сказанного — аналитик не может дать ответ на любой вопрос. Только на небольшое подмножество вопросов — для случаев, когда ему удается из сложного взаимодействия систем смоделировать какую-то сильно упрощенную функциональную конструкцию…
Ньютон понимал, что все физические тела всего мира гравитационно взаимодействуют между собой, что мир — сложная система, но упростил задачу, отбросив весь мир и оставив только 2 тела, разрушив при этом систему (сложную модель) и перейдя к взаимодействию обьектов, к закону (шаблону) их взаимодействия — как функции.
имея функцию — ей можно задать вопрос -входные данные, и получить корректный ответ, вычислив функцию.
системный аналитик — Харон, вечно блуждающий между полуинтуитивно понимаемым миром систем и миром упрощенных доступно формализируемых функциональных зависимостей взаимодействующих изолированных обьектов…
И, также, на то как работают (должны работать) — используя системный подход — моделируя все в виде систем (конструкций из елементов и их связей).
исходя из сказанного — аналитик не может дать ответ на любой вопрос. Только на небольшое подмножество вопросов — для случаев, когда ему удается из сложного взаимодействия систем смоделировать какую-то сильно упрощенную функциональную конструкцию…
Ньютон понимал, что все физические тела всего мира гравитационно взаимодействуют между собой, что мир — сложная система, но упростил задачу, отбросив весь мир и оставив только 2 тела, разрушив при этом систему (сложную модель) и перейдя к взаимодействию обьектов, к закону (шаблону) их взаимодействия — как функции.
имея функцию — ей можно задать вопрос -входные данные, и получить корректный ответ, вычислив функцию.
системный аналитик — Харон, вечно блуждающий между полуинтуитивно понимаемым миром систем и миром упрощенных доступно формализируемых функциональных зависимостей взаимодействующих изолированных обьектов…
Отличная статья, спасибо!
В нашей компании очень много команд разработки. В каждой команде аналитик — это что-то своё. Что уж говорить о разных компаниях… В нашей команде постоянно используют понятия бизнес-аналитик и системный аналитик:
Наш отдел обучения вообще слабо представляет карту компетенции аналитиков, да что уж говорить — вообще никто не понимает. Поэтому нет какого-то плана развития. Мы безуспешно пытаемся пол года собраться и накидать хоть что-то… Могу лишь поделиться с еще одной версий Mind Map.
- Под бизнес-аналитиком понимают тех кто ездит к заказчику, собирает требования, описывает истории и задачи в JIRA, пишет всю документацию (программную и эксплуатационную).
- Под системным-аналитиком понимают тех кто пишет истории и задачи в JIRA в
части интеграций, пишет спецификации (как частный случай программной или эксплуатационной документации)
Наш отдел обучения вообще слабо представляет карту компетенции аналитиков, да что уж говорить — вообще никто не понимает. Поэтому нет какого-то плана развития. Мы безуспешно пытаемся пол года собраться и накидать хоть что-то… Могу лишь поделиться с еще одной версий Mind Map.
Здравствуйте, спасибо за статью. Скажите? ваша последняя схема, была сделана тоже в Confluence?
Какие инструменты (доп.плагины) в Confluence вы используете для построения графиков и диаграмм ?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мифы и легенды системного анализа или чем занимается аналитик в банке