Инструментарий бизнес-аналитика: личный опыт



    Мы не раз рассказывали, как первый же крупный клиент чуть не убил весь наш бизнес. Тогда одной из явных дыр, наряду с QA (Quality Assurance), был BA (Business Analysis). До появления в нашем портфеле по-настоящему больших проектов необходимости в глубоком анализе бизнес-требований заказчика и выработки системных решений для их удовлетворения не было. Сейчас в Redmadrobot три бизнес-аналитика, которые определяют точки развития мобилити-проектов, исходя из бизнес-задач клиентов.
    Один из наших BA — Семен Заморов — поделился своим Toolset, набором программ, которые помогают ему выполнять работу еще быстрее.

    Международный Институт Бизнес-Анализа (IIBA) определяет бизнес-анализ как
    практику создания условий для осуществления организационных изменений путем определения потребностей и предложения решений, которые предполагают выгоду для акционеров.


    В Redmadrobot мы стараемся соблюдать определённый ритм, чтобы чётко выполнять поставленные задачи. В этом нам помогает методология Agile и Scrum. Тайминг очень ценен для аналитиков, не меньше, чем для PM. Именно поэтому мы используем спринт-пульс, который чётко регламентирует срок выполнения набора работ и правильно распределяет активности между участниками команды. По ходу прохождения спринта 20 человек ежедневно вгружают в бизнес-аналитика тонны информации, ведь ВА — это посредник между командой разработки и заказчиком, и с обеих сторон летят задачи и вопросы. Систематизация информации, организация поставленных задач и контроль реализации проектов — очень актуальные темы, о которых я и расскажу.
    Оговорюсь — я использую Mac и Android-смартфон, из-за этого есть некая специфика моего инструментария.

    Из чего все состоит
    Мой Toolset разбивается на две зоны — общую с проектной командой и проектную персональную. К общей относятся задачи по текущему спринту, бизнес-функциональные, функциональные требования и т.д. (ведение задач мы осуществляем в JIRA, требования храним в Confluence). А что делать с остальными активностями, которые относятся к проектной персональной зоне?

    Как все работает

    • 1. Определение скоупа работ. Скоуп формируется в JIRA совместно с заказчиком. Мы стараемся взять побольше задач на оценку, чтобы было, из чего выбирать.
    • 2. Бизнес-анализ и стадия подготовки к оценке. Скоуп задач, как правило, формулируется в виде эпических историй. Именно в виде названий эпиков я создаю набор задач в Wunderlist. Обязательно прикрепляю ссылку на задачу, так легче её искать и трекать.




    Wunderlist. Выбор программы обусловлен ее относительной простотой не в ущерб функциональности. Как приятное дополнение — ее можно использовать на Mac и Android одновременно. При помощи Wunderlist я веду контроль сроков выполнения задач не только мелких и повседневных, но и задач из JIRA. Лучше иметь один общий источник информации, который позволит получить полную картину текущих активностей. Все задачи падают в папку “Входящие” и могут не иметь четкого описания. По окончании рабочего дня я перебираю данный список, уточняю описания, устанавливаю сроки выполнения и раскладываю все по папкам в Wunderlist и ярлыкам в Evernote, которые отчасти пересекаются (Beeline, Redmadrobot, Личное). Такая организация позволяет мне четко контролировать работы текущего дня и планировать ближайшую неделю.

    Далее начинается процесс работы с конкретной задачей. Ручкой в блокнот я выписываю весь набор атомарных пользовательских историй, который, по моему мнению, должен выполнять пользователь мобильного приложения, а также фиксирую особые требования к данным историям в виде примечания. Получается черновик, который можно обсуждать и уточнять с заказчиком. Черновик я фотографирую и отправляю в Evernote. Это помогает при необходимости вернуться к истокам, если что-то в процессе потеряется.



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

    Evernote. Использую его для агрегации всей полученной информации. Важное письмо? Отправляем в Evernote. Записал что-то важное в тетрадь? Фотографирую — и загружаю туда же. Такой подход меня неоднократно спасал. Хлам — вся не разобранная информация — сливается в общий блокнот. Там я держу записи в течение недели. Затем все, что не прошло подтверждение и не стало актуальным, удаляю. Актуализированные записи снабжаю нужным тегом и отправляю в нужный блокнот с названием проекта. Для удобного и быстрого поиска или поиска использую теги.

    • 3. Процесс оценки. Обычный, классический процесс оценки будущих задач и принятия решения о взятии задачи в работу или отклонении и переносе её части или всей в другой спринт. Набор задач фиксируется в JIRA, утверждается с заказчиком и спринт стартует.
    • 4. Системный анализ и проектирование. К этому моменту я уже имею полное понимание о задаче и набор необходимых артефактов для работы. Как правило, если и потребуется консультация с заказчиком, то она будет минимальна и носит скорее характер синхронизации. На данном шаге мой набор действий таков:


    Wunderlist. Задачи, которые не вошли в спринт, уходят из поля зрения в бэклог. Задачи, которые вошли в спринт, снабжаются новыми сроками их исполнения и напоминаниями. Параллельно есть набор задач вне спринта, с длительным сроком выполнения (лично мои задачи по работе).



    — Календарь. В календаре я заранее планирую даты проведения ревью требований с проектной командой (как правило, на 1-2 недели вперед). Это помогает мне поддерживать свой личный внутренний ритм и стараться выполнять все в срок.

    — Mail. Стандартный почтовый Mac-клиент. Самое важное — настройка фильтров. Я использую два обязательных: Today (сообщения только за текущий день) и New (только новые сообщения). Такая система помогает акцентироваться на важном и не распыляться на задачи прошедшего дня. На крайний случай всегда есть поиск.Стараюсь не держать лишнего и сморю только на фильтр Today. Все, что нужно по работе, отправлю в Evernote. Почта для переписки, а не для хранения информации. Информацию, с которой работаю в текущий момент, держу в блокноте SPRINT. Там же провожу системный анализ на основании пользовательских историй.

    — Pomodoro. Контролировать ритм выполнения персональных проектных задач помогает таймер Pomodoro — 11 Pomodoro за рабочий день.

    • 5. Ревью требований с проектной командой. Как только я считаю, что моя работа выполнена, требования на проектирование отправляются в Confluence, и там же оформляются в соответствии с принятыми стандартами. Далее требования проходят проверку проектной командой на понятность, полноту, не противоречивость — в общем, проверку на качество. Некий даблчек.
    • 6. По результатам ревью требования получают повторный апрув от заказчика.


    В итоге мы получаем:
    1. Личную базу знаний в Evernote, наполненную множеством артефактов по конкретной задаче.
    2. Удобный инструмент по агрегации всех рабочих задач на базе Wunderlist.
    3. Инструмент для поддержания ритма работы — Календарь.
    4. Инструмент коммуникации с проектной командой и заказчиком, который не распыляет твое внимание — Mail и фильтры.
    5. Удобный темп работы в течении дня — Pomodoro Timer.
    Redmadrobot 106,20
    №1 в разработке мобильных решений для бизнеса
    Поделиться публикацией
    Комментарии 18
    • 0
      Спасибо за статью. У меня будет несколько вопросов не столько по личным инструментам, сколько о коллективных и немного о процессах. Ответье если будет возможность. Спасибо.

      Скажите, где и каким образом вы аккумулируете полученные требония, классифицируете и связываете (dependency)
      Я справшиваю вот с какой стороны — чаще всего приложение состоит из нескольких модулей/компонентов. В простом случае можно представить как минимум front-end и back-end. Бизнес требования часто запрашивают «фичу» которая сотвественно должна получить реализацию в нескольких компонентах, опять таки по-простому front-end и back-end. Далее, если задача сложная, у нее появляются подзадачи, у какой-то подзадачи может оказаться dependency на реализацию некоторого функционала в другом компоненте. Надеюсь понятно объяснил ход мысли. Что у вас используется для решения описаной проблемы?

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

      • 0
        Добрый день.
        Да, действительно вопрос связан скорее с процессом и в планах появление статьи на эту тему.

        Попробую кратко ответить на вопрос.
        Как описано в статье — все задачи по проекту ведутся в JIRA, требования в Confluence.
        Основным источником, которые все агрегирует — эпическая история в JIRA. Она агрегирует подзадачи и ссылки на требования в Conflunce. Получается dependency ))

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

        Надеюсь сумел ответить на вопрос. Повторюсь, вопрос обширный и требует отдельной статьи. Думаю она появится в скором времени.
      • +1
        Не очень понял, что именно у вас попадает в спринт — готовые требования, или же требования, которые еще требуют разработки, ревью и т.п.?
        Спринты, — насколько я понимаю из картинки, — длиной в 1 месяц?
        • +1
          Павел, спасибо за вопрос.

          Поясню.
          Мы разделяем работу аналитика на уровни: бизнес уровень и системный уровень.
          Изначально аналитик проводит бизнес анализ и описывает бизнес уровень, формирует требования в виде User Stories.
          User Stories попадают на оценку проектной командой (не буду углубляться в процесс оценки).

          Когда решение о включении определенного набор US в спринт принято, начинается этап системного анализа и проектирования. Требования детализируются и формулируются в формате ЧТЗ, Use Cases. Вот уже данные требования проходят ревью проектной командой.

          Да, спринты длятся по месяцу.

          Хочу заметить, что тема процесса актуальна и будет описана в отдельной статье. Здесь я постарался описать мой личный Toolset, которые помогает в работе.
          • +1
            Спасибо за ответ!

            Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?

            Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?
            • 0
              Получается, вы проводите оценку не по детальным требованиям, а по концептуальным? Не выстреливают ли в связи с этим риски? Как с этим боретесь?

              Для оценки данного набор требований достаточно. Это набор атомарных (детальных и независимых) User Stories, а так же специальные требования зафиксированные в виде примечания к story + прототипы экранов от дизайнеров.
              Такой подход позволяет сократить реворк на этапе системного анализа, а так же является стимулом для обсуждения и не ограничивает дизайнера.

              Приведу пример:
              Если я запишу требование в формате «Приложение должно...», то мы получим четко сформулированную постановку. Отклонение от неё недопустимо.
              Если записать требование в формате «Я как пользователь хочу иметь возможность...», то данная формулировка подразумевает множество вариантов решения данной задачи. А уже какой это будет вариант я фиксирую на этапе системного анализа.

              Тема процесса очень актуальна и интересна, с нетерпением ждем. Особенно интересно было бы услышать в статье какого типа у вас контракты (преобладают) — Time & Material, Fixed Price?

              Постараюсь подготовить данный материал как можно раньше. Он требует более детальной проработки.
        • 0
          Спасибо за статью!
          Расскажите, если не сложно, про инструментарий более высокого уровня — техники и методологии, применяемые на практике — мозговой штурм, DFD-диаграммы, анализ бизнес правил итд. И да — применяете ли UML?
          • 0
            Не за что, надеюсь она действительно полезна.
            Я отвечу на вопросы и воздержусь от детального описания процесса. Оставлю эту тему как лакомый кусок на другой раз.

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

            DFD да, но опять же по необходимости. Данные диаграммы нужны, на мой взгляд, на начальном этапе для устранения неопределнностей. Если же идёт фаза развития, то они могут занимать много времени. Практика хорошая, но не панацея. Можете меня ругать за это ). Чаще обходимся UML.

            Бизнес правила, само собой. Без их учёта говорить о полноте требований нельзя.

            Ну собственно да, UML используем, правда как схематичное изображение описанных текстовым способом требований. Я стараюсь распространять правило среди аналитиков, что полагаться на одни лишь схемы нельзя. Возможно это двойная работа, но в действительности необходимое правило.
            • +1
              Если не секрет, какие UML диаграммы вы используете и для иллюстрации каких аспектов — в большей степени для того чтобы зафиксировать онтологию домена или структуру процессов? Диаграммы рисуете в каком-либо специализированном под UML CASE-средстве или же «стандарт де факто» для многих аналитиков — Microsoft Visio?

              Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?
              • 0
                Если не секрет, какие UML диаграммы вы используете и для иллюстрации каких аспектов — в большей степени для того чтобы зафиксировать онтологию домена или структуру процессов? Диаграммы рисуете в каком-либо специализированном под UML CASE-средстве или же «стандарт де факто» для многих аналитиков — Microsoft Visio?

                Павел, используем в основном UseCase и Activity Diagram. Не брезгаем swimline'ми и стараемся описывать полную картину взаимодействия пользователь и приложения.
                Так же применяем диаграмму классов, чаще в статистическом виде.

                Нет, не Visio. Используем продукт компании Sparx — Enterprise Architect.

                Отдельный очень актуальный вопрос — пробовали ли использовать UML для моделирования уровня UI? Если да, насколько эффективным это вам показалось?

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

                В Роботе мы стараемся разграничивать область ответственности дизайнеров и аналитиков. Конечно, от явного пересечения на этапе бизнес анализа не уйти, работаем в паре.
                UML можно использовать для проектирования. Например, Activity Diagram повторяют набор шагов на карте экранов.
                • 0
                  Еще раз спасибо за развернутый ответ. Ваш голос насчет моделирования UI средствами UML засчитан и в очередной раз попал в урну с черными камнями :)
          • +1
            Спасибо за статью огромное!

            У меня два вопроса:

            1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?

            2. Цитата:
            >>Международный Институт Бизнес-Анализа (IIBA) определяет бизнес-анализ как
            практику создания условий для осуществления организационных изменений путем определения потребностей и предложения решений, которые предполагают выгоду для акционеров. >>

            ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?
            • 0
              1. Как оценить сроки работ бизнес-аналитика? То есть. как оценивать загрузку, на основе каких критериев? Я увидел, что это очевидно для Вас. Может поделитесь опытом?

              Оценка работ для аналитика процесс весьма сложный. Скажу честно угадать точно до сих пор не удается.
              Показатель точности зависит от многих факторов: знание предметной области, особенности взаимодействия с заказчиком, опыт коллег и тд.
              Для начала нужно лично для себя определить, что для нас является мерилом. Я использую Use Case. Сложность конкретной задачи можно примерно оценить по количество сценариев, которые требуется написать для её покрытия.

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

              Важно сделать оговорку, что если мы говорим о проекте «с чистого листа», то точность оценки может существенно пострадать в виду большого количества неопределенностей.

              На самом деле я использую несколько техник для оценки. Думаю стоит описать это в отдельной статье. Вы навели меня на мысль )

              ИМХО неверное определение. Анализ — это просто описание. Оно может приносить пользу стейкхолдерам, или не приносить — не имеет значения. Использовать результаты анализа можно как в пользу так и во вред. Это все равно, что от математики требовать полезности. Вы так не думаете?

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

              Анализ — это просто описание.

              В случае документирования требований да, но стоит не забывать, что это только одна из частей.
              • 0
                Если Вы сможете написать статью про анализ трудоемкости работ аналитика с цифрами, я думаю, многие скажут Вам спасибо. А заодно и то, как планировать работу над трудными задачами, не укладывающимися в стандартную временную сетку. Это очень полезный опыт.

                Про бизнес-анализ:

                В моей концепции есть целеполагание, исследование, анализ результатов исследования. Это описание научного подхода. Итак, что есть целеполагание и результаты этого процесса? что есть исследования и результаты этого процесса? и что есть анализ результатов и результаты этого процесса?

                Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
                Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
                Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
                На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.
                • 0
                  Если Вы сможете написать статью про анализ трудоемкости работ аналитика с цифрами, я думаю, многие скажут Вам спасибо. А заодно и то, как планировать работу над трудными задачами, не укладывающимися в стандартную временную сетку. Это очень полезный опыт.

                  Да, думаю это действительно интересно и дополнительная возможность систематизировать данные знания для себя лично.
                  Мог бы предложить следующий способ деления: Все вместе — это проект. В рамках проекта необходимо поставить задачу. Результатом постановки задач являются перечень стейкхолдеров и их интересов.
                  Далее происходит бизнес-анализ. На этом этапе собираются, анализируются и документируются сведения об изучаемой системе.
                  Затем происходит анализ полученных результатов и формулировка предложений по изменению системы.
                  На мой взгляд проект не равен бизнес-анализу, потому что сам анализ лишь часть проекта.

                  Достаточно философский подход. Что первично? Курица или яйцо…
                  Переведу в более понятную для меня форму. Я предпочитаю рассматривать аналитику как независимый процесс, который само по себе целостный. Его результат — это набор проектных артефактов и конкретных решений.
                  Может ли кто-то другой использовать этот результат, не связанный с нашим проектом? Может и зачастую так и происходит.

                  Мне нравится ваша точка зрения. Она не тривиальна.
                  • 0
                    Здесь нет вопроса первичности, но смысл я похоже передал. Если результатами могут воспользоваться и враги, например, то анализ отделен от цели.
                    • 0
                      Здесь нет вопроса первичности, но смысл я похоже передал. Если результатами могут воспользоваться и враги, например, то анализ отделен от цели.

                      ИМХО.
                      Если результатом могут воспользоваться другие люди, в том числе и враги, то вы сделали свою работу правильно.
                      Это значит требования качественные: полные, понятные, непротиворечивые и так далее по списку.
                      • 0
                        Вот это уже похоже на определение анализа. — сбор достаточных с точки зрения поставленных целей знаний о системе, их оформление в виде специально оговоренных заранее артефактов. Прошедшие проверки на полноту, непротиворечивость и логичность. ИМХО — это ближе к определению бизнес-анализа, чем то. что нам предложено. Далее идет работа по созданию бизнес-архитектуры, когда на основе собранных данных, мы предлагаем решение. И к бизнес-анализу архитектурная деятельность уже не имеет отношения. Она просто использует готовые данные и пытается удовлетворить нужным требованиям

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

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