В моем докладе вас ждет немного криминальное повествование о том, какие инструменты нужны для профессии бизнес-аналитика – так, чтобы эта профессия была не скучной, а максимально эффективной и положительной, и приносила свой результат.
Итак, все ненужное мы с вами отрежем скальпелем, все нужное – наоборот, приклеим, но не скотчем, а пластырем. Ну и, запьем это все, наверное, – валерьянкой, чтобы наша душа была спокойна. Начинаем.
Меня зовут Анастасия Штей, я руководитель отдела сопровождения финансового учета самого крупного фудтеха страны. Однако в душе я все еще маленький бизнес-аналитик, к тому же, бизнес-аналитик 1С.
Я считаю, что на руководящей должности важно оставлять в себе частичку экспертизы, из которой мы выросли в руководители. Неважно, с чего начался наш путь – с программирования или бизнес-анализа. В любом случае, руководителем мы становимся не сразу. В моем случае, основой для карьерного роста стал бизнес-анализ, поэтому я считаю себя бизнес-аналитиком 1С.
Компетенции бизнес-аналитика
Прежде чем мы с вами начнем рассматривать инструменты, давайте вспомним, какие ключевые компетенции и навыки должны быть у бизнес-аналитика.
Я попробовала их сгруппировать на шесть частей, и сейчас мы все их рассмотрим – причем, каждая из этих компетенций будет в моем повествовании подтверждаться каким-то инструментом.
Под инструментом мы все-таки не будем подразумевать конкретный программный продукт, мы будем это рассматривать немного шире. Но и не нужно путать эти инструменты с методами, которые используются в профессии бизнес-аналитика.
-
Итак, во-первых, аналитику нужно знание бизнес-процессов. Причем, здесь нужно не просто понимать, что такое бизнес-процесс, а именно – в какой отрасли этот бизнес-процесс, в какой организации этот бизнес-процесс. И, конечно, понимать всю основную логику бизнес-процесса.
-
Во-вторых, нужно понимать, что такое аналитическое решение и решение проблем – нужно быть обучаемым, нужно иметь систематическое и аналитическое мышление, уметь принимать решения.
-
Дальше – нужно владеть определенными навыками взаимодействия и навыками коммуникации. Здесь есть некоторая тонкая грань. Далее я попытаюсь эту грань немного разделить, чтобы вы поняли, в чем отличие навыков коммуникаций и навыков взаимодействия.
-
Также нужны и технические навыки – т.е. умение владеть как специфическим программным обеспечением, так и программным обеспечением общего назначения. Несмотря на то, что я выделила это в отдельный навык-компетенцию, во всех сферах деятельности аналитика в любом случае будут использоваться те или иные программные инструменты.
-
И в заключение – поведенческие характеристики. Это – этика, тайм-менеджмент, доверие.
Инструменты бизнес-аналитика
Итак, начнем. Мы с вами будем заряжать барабан нашего револьвера «пулями» – теми самыми инструментами, которыми мы будем «выстреливать», чтобы наши бизнес-процессы были максимально эффективными, чтобы мы их понимали и дальше интерпретировали. Посмотрим, где можно «застрелить», где можно «потанцевать», где можно «покурить» и т.д.
Здесь я точно так же постаралась выделить шесть областей:
-
инструменты построения бизнес-процессов;
-
инструменты коммуникации и коллаборации – мы с вами обсудим, что означает это сложное слово;
-
инструменты личного развития;
-
дополнительные инструменты;
-
и 1С, причем под 1С в данном случае будет пониматься не только 1С:Предприятие как конкретный программный продукт – мы будем рассматривать 1С как некую экосистему, инфраструктуру, которая постепенно внедряется во все наши области.
Прежде чем мы перейдем уже непосредственно к самим инструментам, я сделаю еще одну маленькую ремарку – важен не сам инструмент, а способ его применения.
С одной стороны, понятно, что микроскопом мы можем забивать гвозди. Но, с другой стороны, наличие микроскопа не делает нас микробиологом. Потому что, во-первых, программный продукт нужно применять своевременно, а во-вторых, его, все-таки, нужно применять по назначению, а не ставить инструмент (программный продукт) во главу угла. Поэтому все перечисленные в моем докладе инструменты в любом случае будут где-то друг с другом пересекаться, где-то друг друга дополнять и т.д.
Сейчас мы с вами поговорим о том, что же делать нам, бизнес-аналитикам, чтобы, посадив маленькое зернышко, получить из него большой урожай – т.е., имея какие-то исходные сырые данные, получить уже непосредственно сам бизнес-процесс. Выясним – с помощью каких инструментов вот это наше «деревце» растет.
Инструменты построения бизнес-процессов
Начнем мы с бизнес-процессов – рассмотрим методы и инструменты для работы с ними.
Здесь список выстроен хронологически:
-
вначале мы собираем информацию;
-
собираем требования к этой информации от наших пользователей;
-
мы проектируем, моделируем бизнес-процессы;
-
анализируем их и оцениваем;
-
и делаем их прототипирование.
Понятно, что не под каждый этап мы можем подвести инструменты – где-то у нас есть и методы. Например, на этапе сбора информации, в основном, используется интервьюирование, анкетирование и т.д.
Поэтому мы рассмотрим в первую очередь инструменты, которые могут быть полезны на этапах сбора требований, проектирования, моделирования и прототипирования.
Инструменты сбора требований
Начнем с этапа «Сбор требований».
На слайде указаны две книги, которые я вам очень рекомендую прочитать, даже при том, что они о программном обеспечении:
-
Карл Вигерс «Разработка требований к программному обеспечению»
-
Элизабет Халл «Разработка и управление требованиями».
Конечно, нельзя поставить знак равенства между требованиями к программному обеспечению и требованиями к бизнес-процессам, но пока что конкретных книг, посвященных разработке требований к бизнес-процессам, не существует. Поэтому мы возвращаемся к этим книгам, которые стали классикой – да, их следует прочитать.
Какие у нас могут быть инструменты, как мы их можем разделять?
-
Во-первых, это инструменты для составления пользовательских историй, такие как Lucidspark, Miro и др.
-
Инструменты для построения диаграмм вариантов использования и диаграмм последовательности. Несмотря на то, что изначально UML появился в продукте IBM Rational Rose, пользоваться им там не очень удобно, потому что это достаточно весомое программное обеспечение, и чаще всего для построения данных диаграмм мы ходим в MS Visio.
-
Инструменты для мозговых штурмов – о мозговых штурмах я буду говорить на протяжении всего нашего доклада, и показывать вам различные схемы. Например, здесь на слайде я привела конкретный пример, как может быть использована одна из диаграмм.
Инструменты моделирования бизнес-процессов
Следующее, что мы делаем – мы моделируем сами бизнес-процессы:
-
С одной стороны, что мы конкретно описываем – сами бизнес-модели в различных видах (здесь представлен целый ворох различных нотаций).
-
И дальше – с помощью чего мы их описываем (используемые программные средства).
Наверняка здесь многие сразу скажут, что не все нотации, которые перечислены на слайде, касаются бизнес-процессов. Соглашусь с вами. Некоторые из этих нотаций находятся около бизнес-процессов и помогают нам описать бизнес-процессы, и в дальнейшем я вам покажу конкретный пример, как это будет помогать.
А если посмотреть на перечисленные программные продукты, то основные вопросы здесь вызывает 1С:СППР, как программный продукт, в котором мы уже можем смоделировать наш бизнес-процесс в одной из нотаций. Многие этот программный продукт обоснованно не любят и могут объяснить, почему он им не нравится – соответственно, они уходят в другие программные продукты.
Чтобы скрестить разные нотации и инструменты моделирования бизнес-процессов – понять, почему мы где-то что-то используем, я подготовила такую табличку:
-
С одной стороны, здесь у нас представлены нотации – не все из них подходят для описания бизнес-процессов, но большинство – подходят.
-
Также здесь видно, какие программные продукты поддерживают эти нотации. Например, если нам для описания какой-то задачи, скорее всего, подходит вот такая нотация – в какой программе нам лучше всего это сделать? Какую программу мне использовать, если моя любимая BPMN какой-то вид описания не поддерживает? Обычно мы просто идем в интернет и ищем ответ там.
-
Кроме этого, если у нас есть какая-то задача, где нам нужно что-то описать, при этом мы не понимаем, с помощью какой нотации это лучше всего сделать – здесь мы можем найти наиболее подходящий вариант. Разных нотаций действительно много, но большинство специалистов не хотят разбираться во всем этом многообразии и становятся приверженцами какой-то одной конкретной, удобной для них нотации, потому что она на данный момент решает для них все вопросы. Но, возможно, стоит обратить внимание и на другие варианты.
Давайте теперь посмотрим конкретный простой пример – мы здесь не будем отвлекаться на все второстепенное.
У нас есть клиент, который делает заказ – он что-то хочет купить, связывается с фирмой, оплачивает и получает свой товар.
Конечно, здесь можно поговорить о том:
-
что клиент хочет купить – товар или продукцию;
-
что оплата может быть предоплатой, постоплатой или смешанной;
-
что клиент может быть юридическим или физическим лицом.
Но мы все это отбрасываем и берем самый простейший пример.
Наша сейчас основная задача будет – описать вот этот бизнес-процесс в различных нотациях с помощью различных программных продуктов.
Первый вариант – BPMN, Bizagi. Все знаем, все любим, все пытаемся его использовать. Почему?
Во-первых, потому что BPMN визуально очень хорошая. Мы в цветовой схеме это понимаем.
Во-вторых, мы строим логическую цепочку этого процесса – у нас есть вход и выход. У нас есть вот эти кубики, которые показывают сам вот этот процесс. И у нас вот эта ролевая структура, в которой мы прямо свой отдел выделяем и говорим – мы здесь коммуницируем, вот здесь и здесь.
Вроде бы все понятно, хорошо, но если мы говорим о бизнес-аналитике, который всегда работает в связке с программистом, то эта схема вряд ли может стать основной для ТЗ. Здесь мы только показываем, какой процесс нужно автоматизировать, и что в ходе этого процесса нужно делать – скорее всего, для программиста это будет просто одной из картинок для понимания.
Мы же все-таки общаемся с программистом не как с кодером, мы не подсовываем ему бумажку с четкими инструкциями, мы понимаем, что наши программисты – люди высокоинтеллектуальные, и они должны понимать процесс, который им нужно дальше уже перекладывать в код.
Поэтому следующий вариант нотации – это расширенный EPC (eEPC), программа ARIS.
С одной стороны, здесь показан тот же самый процесс обработки заявки от клиента, описание последовательности событий – те же самые зеленые и рыжие кубики. Но так как описание модели у нас расширенное, мы здесь даем дополнительную информацию – можем ввести какие-то дополнительные элементы и дать какие-то комментарии. Причем, если в BPMN мы четко видели ролевую структуру, то здесь мы роли можем и не указывать – здесь мы просто выстраиваем логику нашего процесса, а роли уже идут, как довесок.
Но опять же – мы не можем дать эту модель нашему программисту в качестве ТЗ.
Казалось бы, нам нужно просто донести до программиста информацию о том, что мы хотим – более визуально, более просто, чтобы наладить с ним коммуникацию. Что нам делать?
Предлагаю рассмотреть третий вариант – DFD, MS Visio, нотация Гейна-Сарсона. Кто-нибудь использует эту нотацию? Я думаю, что большинство людей ее не использует, считая, что она старая.
Но DFD – это понятно и логично, и именно DFD даст программисту основание, чтобы сделать вывод – какой АРМ будет использоваться, какие данные и из какого регистра будут получаться.
Мы вначале программисту описали сам процесс, он понял эту логику процесса. А дальше мы этот процесс уже в более простом уровне разложили по кубикам и сказали – какая информация будет жить внутри, из какого регистра она будет получаться и в какой регистр будет писаться.
Здесь у нас получается проще – уже идет какая-то коммуникация, мы можем дать нашему программисту конкретное обоснование и для его технического задания.
Но, смотрите, если у нас, например, есть АРМ, то, понятное дело, мы этот АРМ отнесем уже на уровень общения с пользователями. Наш пользователь будет с помощью этого АРМ коммуницировать с конкретной программой – например, с 1С. Как мы скажем программисту, как должен выглядеть этот АРМ, какие в нем должны быть кнопки, и какие табличные части как заполняются?
Инструменты прототипирования
На эти вопросы эта нотация DFD уже не отвечает. Поэтому последующее развитие событий – это инструменты прототипирования.
На данный момент, это всего лишь один слайд для данной презентации. Во-первых, потому что в секции ИТ-анализа докладчики уже рассказывали про дизайн-мышление и прототипирование, и, в целом, они уже достаточно хорошо раскрыли эту тему. Но я не могу о ней не упомянуть.
Когда я готовила этот слайд, я провела маленький опрос среди своих коллег по ИТ и сделала один «звонок другу». Опрос показал, что мое представление о прототипировании в целом совпадает с общим мнением:
-
либо мы разрабатываем рабочую модель – прототип интерфейса, который мы даем нашему заказчику в самом начале проекта, чтобы он ответил на вопрос – совпадает ли планируемая функциональность с его ожиданиями;
-
либо прототипирование используется для визуализации построения макетов.
При этом у нас есть большой подводный камень – считается, что в 1С у нас все-таки дизайна нет, т.е. – непонятно, кто должен проработать дизайн вот этой формы, которую мы отдадим на работу нашему клиенту, заказчику. Бизнес-аналитик должен поговорить с клиентом и нарисовать эту форму? Или это все-таки должен сделать программист – собрать все вводные требования на форме 1С и передать этот прототип на согласование заказчику? Это – основной вопрос, из которого и возникает развитие вот этого направления.
Помните, я сказала, что, когда готовила этот слайд, позвонила другу? Я позвонила Сергею Наумову из WiseAdvice и спросила у него: «Какую ассоциацию у тебя вызывает прототипирование в 1С?» Он мне сразу сказал, что это долгий разговор, и пригласил в Zoom, где мы с ним обсудили достаточно много интересных моментов. Могу сразу сказать, что это – очень обширная тема, и ее, наверное, нужно прорабатывать во всем комьюнити 1С.
Возможно, на следующей конференции мы с Сергеем сделаем совместный доклад на эту тему, потому что здесь можно говорить долго и достаточно интересно. Но пока что для прототипирования мы выделяем только две области:
-
это область визуализации;
-
и область взаимодействия программы с пользователем, которая достаточно обширна.
Инструменты коммуникации
Здесь мы можем перейти в следующую область – в область коммуникации. Но коммуникация в данном случае будет уже не пользователя с программой, а коммуникация уже именно для бизнес-аналитика – внутренняя и внешняя.
Коммуникация в данном случае рассматривается как:
-
взаимодействие бизнес-аналитиков внутри самой команды, где они работают;
-
взаимодействие между различными командами внутри компании;
-
и взаимодействие команды и внешних пользователей, заказчиков.
Обратите внимание, это майндкарта. Вначале, когда я готовила слайд – это был плохочитаемый список. Но потом я поняла – чего я мучаюсь? Проще вот так разложить на майндкарту, где сразу понятно, какие области коммуникации у нас есть.
-
Во-первых, сама коммуникация – сейчас мы общаемся в телеграме, слаке и т.д. При этом у нас до сих пор есть те, кто живет в Skype и не брезгует WhatsApp. Здесь у меня есть даже отсылка к 1С – это сервис 1С:Диалог, это коммуникация пользователей внутри самой экосистемы. Причем, я уже говорила, что 1С – это экосистема, это не просто программный продукт. Поэтому, когда пользователи просят службу поддержки посмотреть какой-то объект системы, они не в почте об этом пишут, а прямо внутри 1С коммуницируют с другим человеком и передают ему ссылку на этот объект.
-
Еще при взаимодействии у нас есть мозгоштурмы – очень классные инструменты, помогающие структурировать информацию.
-
Есть ряд программ общения распределенных команд. Понятно, что мы привыкли к живому общению, мы его любим, но в связи со сложившейся ситуацией мы переходим в Zoom, Google Meet и т.д.
-
И есть такое интересное понятие, как Online whiteboards – для него я хочу привести пример. Давайте посмотрим.
На слайде показан живой пример из практики моего курса по бизнес-процессам.
Здесь дается шаблон бизнес-процесса, причем мы смотрим на бизнес-процесс не как на логику последовательных действий, а рассматриваем каждый из элементов в отдельности. Например, мы смотрим:
-
какие в этом бизнес-процессе есть правила;
-
кто является владельцем этого бизнес-процесса;
-
кто является исполнителем;
-
какие ресурсы;
-
какие входы;
-
какие выходы;
-
кто потребитель;
-
а кто – поставщик и т.д.
Дается какой-то кейсовый случай, и пользователи берут стикеры (например, в Miro) и собирают на этой доске информацию, касающуюся этого кейсового случая.
Например, пишут, кто является владельцем этого бизнес-процесса. При этом, если в группе «Владелец» появилось два стикера, то это значит, что у нас проблема, потому что у бизнес-процесса должен быть только один владелец.
Я считаю, что Miro – это достаточно интересный и полезный инструмент. И в рамках моей презентации вы его часто будете видеть, потому что он достаточно гибкий, его можно использовать в различных моментах.
Инструменты коллаборации
Только что мы с вами поговорили о коммуникации, а теперь пойдет речь о коллаборации – это новый модный термин, у которого есть несколько толкований:
-
Во-первых, коллаборация – это осознанное добровольное сотрудничество с точки зрения работы пользователей на проекте.
-
Но еще есть и термин «коллаборационизм», который означает сотрудничество с врагом – по этой причине слово «коллаборация» многие не любят использовать.
Но я здесь употребляю термин «коллаборация», чтобы обозначить инструменты, которые нужны бизнес-аналитику для работы непосредственно на проекте. Это не те программные продукты, которые бизнес-аналитик использует для себя, а те продукты, которые он должен использовать для работы – например, задачи могут ставиться в Jira, статьи нужно писать в Confluence и т.д. Бизнес-аналитик должен понимать, как пользоваться этими продуктами, но их использование – не цель его непосредственной работы.
Инструменты личного развития
Дальше – личное и развитие. Инструменты, которые уже непосредственно используются бизнес-аналитиком – не направленные на бизнес-процессы, но направленные на его непосредственную работу.
-
Во-первых, это могут быть инструменты накопления знаний, например, системы Wiki. Я очень хочу найти для себя какую-то систему, в которой я могу структурировать, каталогизировать всю информацию, которая накапливается в течение работы. Потому что структура папок – достаточно сложная. И найти в итоге через несколько недель какую-то нужную статью, нужную информацию бывает достаточно неудобно.
-
Во-вторых, мы можем что-то записывать в наших виртуальных блокнотах – у нас могут быть личные таск-менеджеры. Например, если общие задачи мы для себя ставим в Jira, то личные задачи на день мы уже будем для себя вести в MS To Do.
-
Или мы можем устраивать для себя мозговые штурмы. У меня, например, на телефоне стоит программа miMind – очень удобная. Если я, например, к чему-то готовлюсь – к какой-то большой встрече, которая, например, может даже не относиться непосредственно к работе. Я хочу подготовиться, хочу найти информацию – как правило, я в этой программе себе эту информацию структурирую. И порой бывает, когда ты уже структурировал, нашел информацию, сделал для себя какие-то выводы, разложил это все – ты потом приходишь к человеку, начинаешь с ним общаться – он удивляется, откуда ты это знаешь. В принципе, этот инструмент очень хорошо помогает, во-первых, визуализировать все, и, во-вторых, структурировать и дальше уже вести диалог.
-
И заключительное – для личного развития мы можем использовать некоторые инструменты soft skills. Например, я считаю инструментами soft skills презентации и выступления. Для выступлений здесь никакой программный продукт не потянешь. Однако давайте посмотрим примеры инструментов для создания презентаций.
Мастерство презентации
Что будет делать бизнес-аналитик при подготовке к презентации?
-
Сначала он будет искать данные – и здесь ему будут нужны не инструменты, а методы сбора информации.
-
Потом ему нужно будет эти данные структурировать – опять же, на этом этапе у нас опять будут использоваться некоторые методы
-
Следующим этапом, когда мы получим нужную информацию, нам ее нужно будет анализировать и сделать выводы
-
И дальше мы эту информацию презентуем – здесь и начинается самое интересное.
Как мы будем презентовать?
Опять же, рекомендую прочитать книгу А. Каптерева «Мастерство презентации. Как создавать презентации, которые могут изменить мир». Она довольно большая, и, если вы ее откроете, там отсылки ни к каким программным продуктам у вас не будет. Но если вы ее прочитаете, у вас в голове очень хорошо усвоится логика – как выстраивать свое повествование и свою презентацию.
На слайде показана схема содержания этой книги в майндкарте, она помогает уложить в голове информацию после прочтения – вспомнить, что же было в начале и как все эти действия последовательно еще раз сделать.
Если вы будете свои презентации обкатывать по шагам согласно логике этой книги, в принципе, будет уже неважно, какой программный продукт у вас используется – это может быть MS PowerPoint, который все почему-то ругают. Или это может быть Prezi, потому что там картинки лучше и т.д. Неважно.
Если у вас не построена логика презентации – не важно, в каком программном продукте вы ее сделаете, она у вас все равно может провалиться. А выбор уже программного продукта – какой вам удобен, какой вам интересен, в каком получаются более красивые картинки.
Я остаюсь приверженцем PowerPoint – так сложилось.
Дополнительные инструменты
Едем дальше – дополнительное. Мы с вами, в принципе, уже структурировали информацию и знаем, что, когда мы говорим о профессии «бизнес-аналитик» – то, в первую очередь, речь идет об умении описывать бизнес-процессы и владении различными техниками для сбора и анализа информации. Но очень часто в требованиях к вакансиям встречается что-то дополнительное, что может выходить за классические рамки понимания этой профессии.
-
например, кто-то может делать акцент на работу с большими данными;
-
кто-то – на дистанционном формате обучения, хотя у кого-то на это может быть выделен целый отдел;
-
кто-то может потребовать, чтобы бизнес-аналитик также умел хорошо проводить различные тестирования – хотя это тоже, чаще всего, может быть выделено в отдельную вакансию тестировщика. Обратите внимание, здесь я опять делаю маленькую отсылку к такому сервису внутри 1С, как автоматизированное тестирование. Когда я строила всю свою презентацию, я вначале выделила 1С в отдельный блок и хотела там рассказать, какие в этом блоке есть инструменты. Но потом я поняла – это будет достаточно неинтересно и скучно. Поэтому я постаралась на каждую из своих областей, про которые я вам уже рассказывала, сделать отсылку – что для этого существует в 1С. Так вот, оказывается, по сценарному тестированию в 1С есть даже несколько инструментов – на данный момент я изучаю Vanessa Automation, и мне она достаточно интересна.
-
И следующую отсылку, которую я хочу здесь сделать – важно понимать, что инструмент должен всегда работать на нас, а не мы на этот инструмент. Работа с инструментом должна компенсировать вам ваше время. А не так, что вы сели за этот инструмент и тратите на его изучение и работу с ним больше времени, чем работая без него.
Обратите внимание на такой пункт на слайде, как работа с большими данными. С одной стороны, если у нас будет дополнительный навык работы с большими данными, то под этим подразумевается, что мы эти данные должны дополнительно проанализировать. Потому что нашему заказчику или, например, клиенту мы не можем выдать плоскую простыню с данными – мы, в любом случае, должны эти данные как-то визуализировать и презентовать. Отсюда у нас, во-первых, следует презентация того, что мы получили. И, во-вторых, с этим связана работа с инструментами визуализации данных.
Визуализация данных
По части визуализации данных у нас могут использоваться такие известные инструменты, как PowerBI, QlikView и даже 1С:Аналитика.
1С:Аналитика – это, в принципе, небольшой программный продукт, который немного ругают, но я бы его, наверное, ругать не стала. Во-первых, он все-таки существует в самой экосистеме 1С, а во-вторых, вы можете его доработать или даже просто сделать в 1С какой-то свой собственный инструмент, не используя ничего стороннего.
Но почему мы все-таки говорим о визуализации для больших данных?
Как видите, я здесь на слайде тоже задала вопрос – почему визуализация? И ответ оформила в виде простых четырех пунктов.
С одной стороны, они достаточно хорошо видны, вы их можете прочитать – есть за что зацепиться взгляду. Но, с другой стороны, вам все равно нужно читать.
А если я эти четыре пункта представлю вот так? Получилось явно лучше и симпатичнее, хотя это простейший дашборд, который я нарисовала на коленке.
Здесь мы очень хорошо цепляем глазами и сразу получаем информацию.
-
Явно выделяется столбик 80% – именно столько информации мы воспринимаем зрительно.
-
Спустя 2 недели у нас в памяти больше всего остается информации о том, что сказано, и о том, что сделано.
-
50% нейронов нашего мозга воспринимают именно визуальную информацию
-
И понятно, что наличие картинок на 80% повышает наше желание прочитать данный текст.
Как видите, мы взяли данные и превратили их в картинку – логично, что так информация воспринимается удобнее, понятнее и визуально эффективнее.
Выводы
В заключение давайте вернемся к фильму «Криминальное чтиво», который идет «красной линией» через всю нашу секцию. В этом фильме есть чемоданчик, который открывал киногерой, но нам так и не показали, что в этом чемоданчике – мы видели только исходящий от него свет. И, понятное дело, после премьеры все задавали Квентину Тарантино, режиссеру этого фильма, вопрос: «Что же в этом чемоданчике?» На что он отвечал: «Там лежит то, что зритель хочет, чтобы там лежало».
В принципе, мой основной вывод по данной презентации такой – каждый формирует свой «чемоданчик» инструментов, которые ему полезны, которые ему эффективны, к которым он, может быть, привык.
Моя цель была – рассказать, какие инструменты для бизнес-аналитиков существуют, может быть, показать вам какие-то фишечки, которые у меня получилось использовать в своей деятельности.
Поэтому подытожу – каждый сам формирует свой чемоданчик знаний и инструментов.
Вопросы
Вы сказали, что каждый себе формирует свой «чемоданчик». А как же технология? Ведь все в компании должны работать в едином стиле, в единой системе – если каждый сам себе будет выбирать средства, получится хаос.
Не совсем. Понятно, что есть корпоративная культура, корпоративные стандарты. Но все равно, например, для личного использования мы сами можем выбирать нужные для нас программные продукты, которые будут нам идеально подходить. Здесь такое двоякое понимание. Да, если мы придем в какую-то фирму, у них может использоваться линейка программных продуктов Atlassian – и нам нужно будет ее изучить. Но в некоторых случаях мы сами можем что-нибудь предложить, если мы, например, на предыдущем месте работы использовали какой-то другой более эффективный инструмент. Понятно, есть и устоявшиеся технологии, и практики фирмы. Здесь я не говорю, что нужно идти против течения. Но все равно мы формируем что-то свое.
Очень часто выбор инструмента определяется еще и тем, что конкретный заказчик проще воспринимает, и к чему он привык. С этим тоже иногда приходится считаться и подстраиваться под него
Пользуются ли разработчики вашими схемами аналитическими и если да, то в каком формате они их больше любят. И комментируете ли вы их дополнительно как-то текстом или рассказываете словами разработчикам?
На данный момент я стараюсь в процесс для своих программистов вести именно такую визуализацию. И в любом случае, сейчас это даже больше в текстовом формате, но мне хочется это перевести в более визуальный формат. И именно такой визуальный формат призван улучшать работу в связке аналитика и программиста.
В самом начале презентации вы говорили, что в 1С дизайна нет. А как же 1С Maker?
Но это же просто веб-сервис по рисованию 1С-подобного интерфейса. Вы то же самое можете делать в Figma – у Марии Серегиной как раз на конференции был доклад о том, как делать 1С-подобные интерфейсы без всяких дополнительных сервисов.
Как вы относитесь к конфигуратору как к средству дизайна? Для аналитиков вполне было бы неплохо изучить конфигуратор на данном уровне, чтобы создать объект, реквизиты и накидать все это на форму – вот вам, пожалуйста, и прототип.
Это достаточно дискуссионная тема. С одной стороны, бизнес-аналитик должен понимать, что такое конфигуратор, но настолько он в конфигуратор лезть не должен – для этого есть программист. Отсюда нужно понимание, кто проектирует интерфейс – бизнес-аналитик или программист. В зависимости от этого и принимать решение.
*************
Данная статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere. Больше статей можно прочитать здесь.
Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/
*************
