Мифы и легенды системного анализа или чем занимается аналитик в банке

    Привет! Меня зовут Настя, я аналитик мобильного приложения Альфа-Бизнес. Иногда меня спрашивают о том, чем я занимаюсь на работе. Друзья, родные и, как это ни странно, разработчики. Каждый раз я отвечают по-разному, пытаясь привести наиболее близкие собеседнику примеры.

    «Системный аналитик переводит требования пользователей с человеческого языка на разработческий…» — звучит довольно понятно для человека, не связанного с ИТ. Но если ты непосредственно участвуешь в разработке, вряд ли такого определения будет достаточно. Ради небольшого эксперимента я задала своей команде вопрос: «Чем занимается системный аналитик?». Читаем под катом, что из этого получилось.


    Для меня системный аналитик — это человек, который может дать ответ на любой вопрос: от «Как должна работать фича», до «Почему Земля круглая» (с) тестировщик
    
Насчёт Земли, может, и перебор, но в остальном довольно точно. Где хранить данные, как их передавать, как работает фича, почему фича не работает… Каждый раз, когда в бэклоге продукта обнаруживается что-то непонятное, следует фраза «нужна аналитика».

    Чтобы понять, как работает система, аналитик обращается к внутренним документам. Обычно ответ находится среди текста, схем и таблиц. Но иногда люди уходят, не написав документацию. Или она неактуальна. Или недостоверна. Карма таких аналитиков страшно страдает, но, к счастью, есть другие способы найти информацию.

    Уверенное использование систем логирования может сократить чтиво с 30-страничного ТЗ до нескольких запросов. Главное — знать, что искать. В логах содержится информация о вызываемых методах, входных и выходных параметрах, причинах ошибок. Если сервис композитный — о пошаговом выполнении операции. Аналитику нужно разбираться в структуре логов и уметь их фильтровать: логируется обычно огромный объем данных.

    Информацию, найденную в логах, хорошо дополняет поиск по коду приложения. В проекте кроется информация об источниках данных, логике обработки переменных и много других нужных вещей. Успешность мероприятия зависит от скилов аналитика и особенностей компании. В некоторых организациях аналитики не имеют доступ к коду. Правильно это или нет — вопрос сложный. В любом случае, если нет доступа (или понимания происходящего), всегда можно спросить у разработчика.

    Если появляется задача, которую никто не решал, в ход идут внешние источники. Окей, Гугл, космологические модели Вселенной? Тут хороши любые средства: статьи, форумы, обучающие курсы, документация на сторонние системы. Иногда на помощь приходят индусы с ютуба, но это крайний случай. Кстати, уметь искать надо на двух языках, ну или сразу на индусском английском.

    Еще один источник информации — это люди. Аналитик, знающий предметную область, может за пять минут решить задачу, на выполнение которой ты наметил пару дней. Поэтому нужно знать, чем занимаются коллеги вокруг, и уметь правильно сформулировать свой вопрос.
    Аналитик как навигатор, прокладывает путь до цели, огибая препятствия, и постоянно ищет более короткие пути (с) фронтенд-разработчик
    Чтобы добраться из Петербурга в Саратов, нужны надежная машина и автомобильная карта. Хорошо, если есть аптечка, запаска, инструменты. Не будет лишним навык общения с местными жителями, ну и в целом понимание, зачем ты едешь в Саратов, а не в Краснодарский край, например. С аналитикой так же. У тебя должны быть инструменты для работы, умение взаимодействовать с людьми и четкое понимание ожидаемого результата. Дорожной картой становятся знания о системах и технологиях.

    У любой задачи есть, как минимум, два решения. Важно выбрать путь, который будет не короче, но правильнее. Правильнее с точки зрения архитектуры, выполнения продуктовых требований и затрат на реализацию. Иногда аналитик только предоставляет информацию для командного решения, в других случаях — делает выбор сам.

    Чтобы предложить адекватную реализацию, нужно хорошо понимать устройство системы: от архитектурных паттернов до технологий разработки. Внедряя изменение, аналитик оценивает влияние на компоненты приложения и другие интегрированные системы. При разработке мобильного приложения нужно помнить про пользователей со старыми версиями. При наличии у системы несколько фронтов — про единообразие их работы. При использовании нескольких источников данных — про их консистентность. В общем, головной боли увлекательных особенностей в работе хватает.
    Ну не знаю, ты для меня просто тестировщик. Ну, или смесь продакта с тестировщиком, как-то так (с) бэкенд-разработчик
    Согласна, звучит немного обидно, но доля истины тут есть. Сначала аналитик исследует систему, чтобы понять, как она устроена. Потом убеждается, что результат труда разработчиков работает правильно на всех уровнях: база содержит достоверные данных, сервис возвращает корректный ответ, пользователь видит ожидаемый результат. Если что-то идёт не так, выясняется уровень ошибки, причина несоответствия и возможные варианты исправления. Оценка соответствия системы различным видам требований — неотъемлемая часть аналитики.

    С продуктовым аспектом сложнее. Владелец продукта знает, что нужно делать, чтобы пользователь был счастлив. Системный аналитик знает как. Мое субъективное мнение — аналитик в той же степени, что и другие участники команды, должен (или может) заниматься продуктовыми вопросами. Когда вся команда беспокоится об улучшении пользовательского опыта и достижения финансовых целей, рождаются лучшие решения, чем когда этим занимается один или несколько человек.
    Собирает информацию о продуктах, проектах и системах банка, занимается ее актуализацией и распространением, находится на острие информационного ножа (с) скрам-мастер
    С документации все начинается, ей же и заканчивается. Она готовится для внутреннего использования и, где это применимо, для Заказчика. Документы создаются в соответствии с ГОСТ-ом или по внутренним стандартам. Способы документирования также могут отличаться по слоям систем.

    При написании документов в ход идут различные методики, стандарты и нотации моделирования систем. Редко когда нужно безукоризненное следование правилам. Должно быть достоверно и актуально. А если понятно с первого раза, то вообще замечательно. Тут, кстати, есть интересная статья, в которой раскрыта проблема качества документации.

    Помимо системных документов аналитик может писать материал для корпоративной Wiki. Узнал что-то новенькое — расскажи другим. Хочешь поделиться опытом — выступи с докладом. Опять же, так бывает не всегда и не везде. Но если на предприятии есть процесс управления знаниями, аналитики обязательно принимают в нем участие.

    Есть много разных вещей, которые должен знать аналитик, чтобы соответствовать роли и ожиданиям команды. В зависимости от специфики продукта и отрасли состав и степень их значимости меняется. Что делает аналитик, мы, вроде, разобрались. Осталось понять, что нужно знать для успешного выполнения всех задач. Вашему вниманию предлагается дорожная карта аналитика. Схема содержит основные скилы по разным направлениям, а также попытку провести различия между системным и бизнес-анализом.

    Насколько карта универсальна, мне судить сложно. Поэтому жду комментариев от разработчиков и аналитиков из других организаций :)

    Альфа-Банк
    153,69
    Компания
    Поделиться публикацией

    Комментарии 47

      +2
      Аналитик это человек который формализует бизнес требования, дополняет бизнес требования не функциональными требованиями (требования к качеству и характеристикам).
      А вот всё остальное про чтение кода, чтение логов, просчёт последствий изменений в бэкэнде на фронтэнд, и прочая прочая это не аналитик. Это архитектор если по технической части, UX/UI дизайнер если по видимой части работы программного продукта и прочие люди которые тоже нужны и которые тоже имеют свои участки ответственности.
      Аналитик это не тот кто знает всё и может во всё разобраться. Всё про систему на троих знают: владелец продукта, архитектор, админ отвечающий за эксплуатацию (настройка окружения, выкатка, мониторинг текущий метрик, обеспечение стабильного функционирования).
        +1
        Согласен, все что в roadmap слева это не про системного аналитика, а про архитектора.
        Оббежать всех ЛПР на стороне заказчика, записать их хотелки, хорошо-бы еще под протокол. Перевести все что нужно в use cases, описать деревья требований хоть в requesitPro, сформировать детальные спецификации на каждый модуль, отдать в разработку. Если разработчику требование непонятно — обьяснить/исправить описание на понятное. Если у заказчика новая хотелка — оценить ее взаимовлияние на уже проведенные работы, если цена изменения согласована, провести изменения во всех связанных сущностях.
        А вот траблшутинг и прочее с тестированием — это не дело аналитика.
        Во всяком случае так было 15 лет назад.
          0
          kagarich, возможно, сейчас требования к аналитикам стали выше
            +1
            Да нет, просто есть компании, которым нужен специалист поддержки, девопс, аналитик, архитектор, тестировщик, дизайнер, UX-проектировщик и техпис, всё это не считая разработчиков и управленцев.
            А есть те, которым нужен эникейщик, чтоб умел всё и подешевле. Как умеет — не так уж и важно, всё равно никто не разбирается.
            0
            C одно стороны вы правы, аналитик это в первую очередь требования.
            С другой, вот приходит заказчик и говорит, хочу видеть на одной странице в браузере всех пользовательзователей филиала (пример кстати реальный хоть и из совершенно другой области).
            И вроде нормальное требование, но если вспомнить что пускай в одном филиале может быть 10 тыс пользователей, а также если есть хотя бы елементарное понимание как это все технически работает, то сразу становиться ясно, что веб-страничка с полноценной таблицей на 10000 строк будет безбожно тормозить.
            Более того в таком случае не делая круг к девам, можно сразу копать дальше с вопросами, типа «а где и как и вы это будете использовать, как часто и что хотите увидеть», в результате которых подобное требование и вовсе может отпасть.
            Вот так приходиться по чуть-чуть, но вникать в вроде бы и «не нужные» вещи как-то код и
            логи.
              0
              Все так. Я не утверждаю, что аналитик это машинистка, которая тупо записывает хотелки заказчика. Аналитик, это человек, который имеет широчайший кругозор по всему стеку применяемых технологий, от фронта (HTML, JS, апплеты, флэш и т.п.), до бэкенда (СУБД, access, identity, и т.п.), более того, он понимает в сетях на уровне forest / domain, firewall / ports / protocol. Все это не для багфиксинга, а для корректного сбора и управления требованиями, чтобы на этапе интервьюирования и документирования не говорить/писать откровенную чушь, на ходу управляя хотелками заказчика "… вы знаете, если вот это ваше требование реализовать, то загрузка интерфейса займет более 10 сек, и потребует вот такой-то конфигурации на клиенте, давайте рассмотрим вот такой вариант, он позволит..."
                0
                Чтоб понимать, что страничкой с полноценной таблицей на 10000 строк будет невозможно пользоваться, бегать круги к девам не нужно, ИМХО. И вовсе не потому, что будет тормозить…
                  0
                  Увы, слишком много людей привыкло к Excel, и пытается его притянуть куда надо и не надо. Я вот честно не могу понять, как можно работать с таблицей (даже того же екселя), которая по ширине не вмещается в стандартный монитор 20 дюймов.
                  Однако заказчики такие файлы приносят с завидной регулярностью.
                    0

                    Для передачи данных это нормально, для экспорта. Но не просмотра глазками

                      0

                      Так в чистом виде не смотрят, используют фильтры)сортировки и прочую пост. обработку, но проблема в том что формализация этого процесса часто невозможна (либо реализация всех вариантов дороже чем "как есть" в сотни раз).

                        0
                        Когда есть фильтр — к просмотру остаётся куда меньше записей. Когда есть сортировка — вполне работают лимиты пагинации, и тоже к просмотру остаётся небольшой обозримый кусок из начала сортированного списка.

                        Я до сих пор удивляюсь, почему в огромном количестве средств просмотра таблиц фильтры и сортировка как правило чрезвычайно убогие… Что онлайн, что даже в толстых клиентах ERP-систем…
                          0

                          Вы наверное меня не совсем поняли, фильтры они в голове, включаются в зависимости от ситуации…
                          Про пагинацию, ну это вы не про отчётность явно, и не про наборы в сотни тысяч строк после фильтрации и обработки...

                            0
                            Фильтры должны быть в компьютере, достаточно удобными и функциональными, чтоб не держать их в голове и не мотать километровые простыни.

                            И да, в том числе для отчётов, которые смотрят глазками. А те отчёты, которые глазками не смотрят — те и не смотрят, так что мы сейчас не о них.
                              0

                              Я так тоже считаю, но реальность она другая, процессы, правила, алгоритмы — всё меняется и очень быстро, на рынке до сих пор нет "универсального решения" с обозримым горизонтом времени на настройку/доработку, у каждого крупного игрока свои костыли/эксели и "продвинутые пользователи. И дело не в том что "денег не дают", просто формализация не поспевает за изменениями.

                                0
                                В табличках и фильтрах к ним сильно меняться почти нечему.

                                Но да, на рынке явных массово пригодных решений по-прежнему нет. Я вот и удивляюсь, почему они не востребованы и большинство забивает вовсе либо лепит себе кривые костыли…
                                  0

                                  Я вроде уже писал: сделать универсальное решение — написать свой excel :)
                                  Решения есть от крупных вендоров за очень много денег, но проблема в том что чуть шаг влево шаг вправо, они перестают работать как надо, а доработка (если не брать финансовую составляющую) просто не успевает не только за требованиями бизнеса но и за требованиями регулирующих стандартов.

              0
              Без архитекторов и дизайнеров никуда, согласна
              Однако в масштабах банка архитектора занимаются более глобальными вопросами, нежели анализ влияния изменений на конкретный продукт (систему)
              Что касается саппортов — здорово, когда причины багов находятся без участия продуктовых команд. Но не всегда поддержка имеет возможность подгружаться в задачу на уровень, необходимый для ее решения. Так задача возвращается на аналитика
            0
            Работаю БА/СА в Альфе 3 мес, ничего так, отличная атмосфера!
            Имхо, в карте нету технологий по работе с фреймами/мокапами таких как Axure или moqups.com.
            Ну а в целом добавляю в закладки «на случай важных переговоров» (достало вечно объяснять человекам одно и то-же)
              0
              По идее, аналитик и владелец продукта должны быть одним и тем же лицом
                +1
                Хорошо, когда аналитик немного продакт и наоборот — это помогает взаимодействию
                Но управление бэклогом, приоритизация задач, защита проектов — точно не задачи для системного аналитика
                  0

                  Почему Вы так думаете? Лично я знаю хорошие примеры, когда аналитик отлично рулит бэклогом и проекты защищает.

                    0
                    Аналитик может успешно выполнять эти функции
                    Но тут получается совмещение ролей, а не системный анализ в чистом виде
                +1
                6 лет проработал в IT банка, когда наняли аналитиков работать стало намного сложнее. Вроде как они должны были формализировать требования и описать их ясным языком на практике они их искажали и частично пропускали. Кроме того пришлось их еще и учить, т.к. ничего не знали с начала. В добавок еще аналитики занялись интригами, т.е. не тем чем должны. Т.е. мой опыт работы с ними негативный.
                  0
                  Грустно, что вам пришлось столкнуться с аналитиками-интригантами
                  Мы стараемся делать работу разработчиков проще, а не наоборот :)
                    0
                    учить людей которые пришли с улицы это нормально. Интриги это издержки коллективной работы. Не повезло вам с людьми, но это именно люди, а не специфика профессии.
                    +1
                    Более бессмысленных сотрудников, чем аналитики в банке, просто нету. После пары лет бессмысленных метаний, я просто продемонстрировал всем их недалекость и запретил им соваться в мою область.

                    Если речь об анализе внешних факторов, то это лучше сделают соответствующие агенства. Если речь о внутренних бизнес-процессах, то они понимают меньше, чем профильные подразделения. Можно заказать такой анализ опять-таки агентству, но и от этого будет мало толку, только если вы не потенциальный покупатель банка.

                    В итоге резюме — уволить их к чертям. За счёт экономии усилить профильные отделы.

                    P.S. Я видел нужных аналитиков — в IT-компании. Но они были полезными, если вырастали туда из внедренцев, тестеров. Видел сотрудников банка, которые сами не зная того, занимаются анализом очень хорошо. Так что против самого процесса анализа я не против.
                      0
                      Это хорошо если последняя линия поддержки, норовят то и пораньше выставить:) Похоже вы попали на толпу джунов-аналитиков, которых массово набрали как дань моде или в попытке что-то быстро решить. Аналитики, ради аналитики действительно бесполезны, а эту роль может выполнять и нередко выполняют люди с другой должностью на визитке. Для эффективной работы аналитику, кроме непосредственно хард-скиллов аналитика нужно и понимание предметной области. В некоторых непростых доменах обучение довольно длительное, особенно, когда оно не выстроено как система. В таких случаях толковые люди, которые давно в этой организации имеют неоспоримое преимущество и дадут фору большинству аналитиков.

                      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 и у него(ё) начнет скрипеть мозг :)
                        +1
                        astralNord похоже, с «дорожной картой» тут сложности перевода) целью было не предложить конкретный план, а скорее изобразить направления для развития. Поэтому ни конкретики, ни сроков тут нет

                        Насчет архитектуры не согласна. Во-первых, мидл-разработчику эти слова должны быть как родные. А что касается аналитика, ну как он может описать решение по интеграции, не зная даже, как общаются клиент и сервер
                          0
                          1. Причём тут сложности перевода? Вы в статье использовали и русскоязычный и англоязычный термин, в обоих языках это план, долгосрочный и очень укрупнённый. Планы бывают с разным горизонтом и разной степенью детальности.
                          Если вы хотели просто накидать перечень терминов, технологий, понятий, знаний, навыков и умений, которые по вашему мнению полезно знать системному аналитику, то так и пишите «перечень/список… », а не Roadmap. Точность формулировок — это один из важнейших хард-скилов аналитика, ведь люди с разным опытом и знаниями выдаваемые вами тексты/документы должны как можно однозначнее понимать. Растекаться водой по древу — это к маркетологам, а не аналитикам.

                          2. Так в том то и дело, что для разработчика они обычно родные, потому и такое перечисление вызовет недоумение, как минимум наличием в этом списке client-server (остальные перечисленные тоже client-server), так и то, что вы затронули только один из многих аспектов проектных решений, совокупность которых и складывается в архитектуру.
                          А что касается аналитика, ну как он может описать решение по интеграции, не зная даже, как общаются клиент и сервер

                          Это верно, но раз уж начинаете термины употреблять, лучше знать, что они означают.
                        0

                        "В итоге резюме — уволить их к чертям. За счёт экономии усилить профильные отделы."
                        Но по сути же теми же аналитиками :)
                        А так бывают ситуации когда задача пройдя все тернии процесса согласования и анализа в итоге от разработчика возвращается тебе же с просьбой таки объяснить, "поделиться скриптами"… (А то и заказчик исполнителем становится, но это конечно исключения).

                        +1
                        В идеальном мире — аналитик только про требования. В реальности же (системный аналитик в ИТ крупного ретейлера):

                        • бизнес-анализ, помощь БА
                        • подготовка требований
                        • разработка архитектуры
                        • тестирование изменений
                        • последняя линия техподдержки
                        • приоритезация и планирование изменений продукта (совместно с заказчиком)
                        • организация внедрения изменений
                        • управление проектом (когда изменения масштабные)
                          0

                          Согласен полностью

                            0
                            Разработка архитектуры — задача архитектора (как должно быть ясно из названия). Это совершенно другая специализация. Талантливый человек может, конечно, охватить обе, но для эффективного использования ресурсов он должен заниматься чем-то одним.
                              0
                              @lobomic, в чем вы видите отличия в специализации?
                              обычно в архитектора и вырастаю из аналитиков (если, конечно, вы имели ввиду не архитектора ПО)
                                0
                                Я, конечно же, имел в виду архитектора ПО. Кроме него я знаю только архитектора данных, но он, по-моему, занимается более глобальными вопросами, чем отдельное приложение. В некоторых фирмах архитектором ещё называют «технолога», который выбирает технологии для приложения. Это тоже, в общем-то, развитие разработчика. А какой же архитектор может вырасти из аналитика?
                                  0
                                  А какой же архитектор может вырасти из аналитика?

                                  Собственно, системный архитектор. Тот, кто способен оркестрировать развитие систем на уровне их взаимодействия. Подробнее тут en.wikipedia.org/wiki/Systems_architect
                              0
                              не, далеко не последняя линия техподдержки.
                              0
                              Да трудно тут явно сказать. Уровень и зона ответсвенности аналитика отличается не то, что в разных компаниях, а и в рамках одной компании или более того команды. Пожалуй, аналитик самая размытая специальность на нашем рынке. По сути он задействован на всех этапах работы над проектом/продуктом, как до запуска, так и после.
                              Чем меньше компания, тем больше обязанностей на аналитике: спроектировать архитектуру решения, выгрузить какие либо данные для отчетности, разобраться с дефектом, помочь тестированию, уладить конфликт разработчиков разных платформ.
                              Если же говорить про большие компании, то там с этим попроще, потому что народу гораздо больше. В некоторых банках аналитики пишут документацию, отдают ее архитекторам или еще кому нибудь(всевозможные тех советы), где она после согласования передается в разработку. Больше аналитик с описанной им функциональностью не сталкивается и занимается новым документом. Постепенно от этого подхода уходят, поднимая флаги разнообразных agile, однако большинство забывают, что при таком подходе нужны еще и компетентные управленцы в составе этих команд. Этих людей можно назвать, что техническими менеджерами, что архитекторами. А таких людей почти нет, потому что потребности в них особо и не было. Часто менеджеры умеют работать с бизнес требованиями в лучшем случае и предоставлением некой формальной отчетности по стадии проекта. Самое тяжелое же бремя ложиться на аналитиков, потому что резко появилась необходимость работы с требованиями/поддержкой/аналитикой/планированием 24x7, а для этого необходимо довольно сильно погружаться в весь проект и около него, что не любят делать менеджеры (я лишь должен требовать от команды), программисты (дайте мне правильно поставленную задачу и отстаньте от меня со своими постоянными встречами). Рынок же по сути не был готов поставлять специалистов, что заметно по дефициту этих «эникейщиков», которые делают описанные на диаграмме из статьи вещи, на рынке.
                                0
                                Насчет размера компании — хорошее замечание
                                Добавить к этому кроссфункциональность, присущую скраму, и обязанности аналитика могут увеличиться до бесконечности
                                +1
                                системный — указывает на то, с чем работают — системы.
                                И, также, на то как работают (должны работать) — используя системный подход — моделируя все в виде систем (конструкций из елементов и их связей).
                                исходя из сказанного — аналитик не может дать ответ на любой вопрос. Только на небольшое подмножество вопросов — для случаев, когда ему удается из сложного взаимодействия систем смоделировать какую-то сильно упрощенную функциональную конструкцию…
                                Ньютон понимал, что все физические тела всего мира гравитационно взаимодействуют между собой, что мир — сложная система, но упростил задачу, отбросив весь мир и оставив только 2 тела, разрушив при этом систему (сложную модель) и перейдя к взаимодействию обьектов, к закону (шаблону) их взаимодействия — как функции.
                                имея функцию — ей можно задать вопрос -входные данные, и получить корректный ответ, вычислив функцию.
                                системный аналитик — Харон, вечно блуждающий между полуинтуитивно понимаемым миром систем и миром упрощенных доступно формализируемых функциональных зависимостей взаимодействующих изолированных обьектов…
                                  0
                                  С вашей метафоры хоть новую статью начинай :)
                                  +1
                                  Отличная статья, спасибо!
                                    +3
                                    В нашей компании очень много команд разработки. В каждой команде аналитик — это что-то своё. Что уж говорить о разных компаниях… В нашей команде постоянно используют понятия бизнес-аналитик и системный аналитик:
                                    • Под бизнес-аналитиком понимают тех кто ездит к заказчику, собирает требования, описывает истории и задачи в JIRA, пишет всю документацию (программную и эксплуатационную).
                                    • Под системным-аналитиком понимают тех кто пишет истории и задачи в JIRA в
                                      части интеграций, пишет спецификации (как частный случай программной или эксплуатационной документации)

                                    Наш отдел обучения вообще слабо представляет карту компетенции аналитиков, да что уж говорить — вообще никто не понимает. Поэтому нет какого-то плана развития. Мы безуспешно пытаемся пол года собраться и накидать хоть что-то… Могу лишь поделиться с еще одной версий Mind Map.
                                    image
                                      +1
                                      Какая подробная карта, спасибо!
                                      0

                                      Здравствуйте, спасибо за статью. Скажите? ваша последняя схема, была сделана тоже в Confluence?
                                      Какие инструменты (доп.плагины) в Confluence вы используете для построения графиков и диаграмм ?

                                        0
                                        последняя схема была сделана в XMind
                                        в confluence знаю макрос Drawio, но мы его не используем
                                        а так, по-старинке — Visio, и для документации на бэк — PlantUML (плагин Idea)

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое