Михаил Бахрах "Бизнес-анализ от а до я: гид для начинающих"

Project manager – Руководитель проекта

Business analyst/ Data analyst – Бизнес аналитик / Дата аналитик

Solution Architect – Архитектор решений

UX Designer – Дизайнер Пользовательского опыта

И если взглянуть на рейтинг навыков, то еще в 2020 году Линкедин опубликовал такую интереснейшую статистику:

В 2020 году среди всех навыков Бизнес-анализ стоял на шестом месте – это же потрясающе!

Примечание автора: данные на английском языке. Перевод:

The Skill Companies Need Most in 2020 – Навыки компании нуждаются больше всего в

2020 году

Top 10 Hard Skills – Топ 10 “жёстких” навыков

Business analysis – Бизнес анализ

Вот и закончилась первая история и надеюсь вам она понравилась, перед тем как “нырнуть” уже в БА жизнь в следующих историях и главах.

Каким итогом об этой истории я бы хотел закончить (уже точно!) – попытаться трудоустроится, как процесс не так сложно, а вот подготовиться, учесть все нюансы и перспективы и принять правильные решения – вот это уже может потребовать времени. Естественно, это применимо к любой профессии и цель это истории была показать именно специфику БА трудоустройства.

Вторая история о том, как может выглядеть начало карьерного пути БА

Как обычно начну с вводной, что и как будет происходить в это истории. С точки зрения описания навыков регулярного бизнес-аналитика эта история будет содержать основное описание, поэтому я добавлю еще один уровень разделения и декомпозиции описательной части внутри истории – шаг. У нас теперь есть глава, потом внутри идут истории и внутри историй будут шаги – как базовый элемент движения. В этой истории шаги будут отражать моё поэтапное развитие как ИТ БА внутри одного уровня (обычный регулярный БА). В каждом шаге я описываю свой профессиональный рост, задачи/активности, чем я занимался. Так же я детально рассказываю про те навыки, которыми на мой взгляд должен обладать БА. Плюс опишу практические примеры, как и зачем я применяю навыки и активности. После всех шагов я опишу/нарисую и объясню жизненный цикл или взаимосвязь навыков и активностей – ведь должна же между ними быть связь. Так же я дам рекомендации, когда, в каких ситуациях использовать те или иные навыки и активности. Ну и закончу как обычно интересным итогом про данную историю. А теперь немного самого контекста – о чем именно будут шаги, и какая связь будет между моим развитием, описанными навыками и под-уровнями БА. Будет представлено 4 шага, чтобы равномерно распределить смысловую нагрузку:

В первом шаге я опишу свой старт как БА (о чем я кратко уже упоминал в предыдущей истории) в своей первой ИТ компании. На этом шаге я работал можно сказать помощником опытного БА. Я в основном создавал небольшие куски требований. Во втором шаге я описываю период, когда я уже достаточно «набил руку» в работе с требованиями и рассматриваю себя как самостоятельного БА, который может описывать и управлять требованиями по определенной функции (feature) системы. На третьем шаге я уже увеличу масштаб до работы с требованиями на уровне компонента системы. А в заключительном четвертом шаге я уже буду работать как продукт овнер (product owner – владелец продукта) ответственный за компонент системы.

Если говорить про временные рамки, описываемые ниже моего становления как регулярный БА, то это примерно 1,5 года в период с марта 2013 до конца 2014 года. И после я уже перешел в какое-то промежуточное состояние, когда я еще не был официально старшим БА, но уже выполнял его функции в следующие 4-6 месяцев до второй половины 2015 года. То есть плюс минус мне потребовалось около 2 лет, чтобы стать хорошим начинающим старшим БА или просто отличным БА.

Время, которое необходимо каждому человеку, чтобы получить/прокачать навыки конечно же всегда индивидуально + зависит от окружающего контекста – компании, где работает человек, вида проекта/команды/ методологии/проф уровня команды и так далее. Кому-то может потребоваться 1 год, а кому-то 4 года, чтобы стать высококвалифицированным БА, готовым к переходу на следующую позицию. Единственное, что не индивидуально, это ожидания «контекста» (проекта/продукта/внутренней /внешней команды) об уровне владениям навыками БА и это и есть «контрольная точка», чтобы понять лично для себя уровень. Моя книга это именно та «подсказка», которая помогает развитию бизнес-аналитиков в понимании уровней и определения навыков БА, как я это вижу на основании своего опыта.

Теперь немного про уровни внутри позиции “регулярный БА”. Первый и второй шаги я привязываю к первому уровню БА, который я бы описал как «стабильный и уверенный создатель требований». Регулярный БА, который может свободно определить и задокументировать требование к определенное функции – это его основная задача и требование к уровню. Я не случайно привязал целых два шага своего развития в компании к одному уровню, так как считаю, что на старте своей БА карьеры самый важный акцент БА должен сделать на ключевой активности/навыке, которую он будет использовать и развивать все последующие годы в независимости от других навыков и активностей – это умение «правильно» задокументировать требования. Что есть «Правильно» я расскажу ниже в этих шагах 1 и 2. Второй БА уровень привязан к третьему шагу и он отражает БА, который может работать на уровне функции системы, который создает логичные и высокого качества требования, а так же профессионально взаимодействует с командой и может выполнять роль владельца функции. Он использует логически правильную структуру требований для документирования и понимает жизненный цикл требований, следит за рисками и понимает кто-есть-кто среди его ключевых клиентов (stakeholders) и зоны их ответственности и если потребуется, то так же может коммуницировать с клиентами при поддержке со стороны проектного менеджера или ведущего БА. Такой БА имеет знания о жизненном цикле проекта. Он само-организован, умеет доставлять мысли, идеи, вопросы, решения в понятной и удобной форме. Третий уровень отражает уже зрелого регулярного БА, который уже возможно частично выполняет обязанности старшего БА и готов к переходу на новую позицию/должность. Такой БА работает так же, как владелец компонента. Понимает и может заниматься оценкой своих время/трудозатрат и знает как оценки делаются на уровне проекта, разбирается в плюсах и минусах разных методологий, доверенное лицо проектной команды и клиентов. Такой БА уже разбирается в подходе к выявлению требований, в том числе знания о дискавери (discovery) фазе, работе с изменениями в требованиях и эффективно планирует свое рабочее время, в соответствии с приоритетами задач. Уточню очень кратко про термин “Дискавери фаза” (Discovery phase), так как использовать я его буду косвенно часто, а вот детально мы его коснемся только в самом конце книги. Простыми словами и коротко – Дискавери фаза – это обычно активность в специально выделенный временной промежуток по выявлению самых первоначальных целей проекта/продукта, требований и границ планируемого решения. Обычно, это как раз самый первый этап любого начала проекта/продукта.

Зачем я написал про эти уровни внутри регулярного БА? Для меня важно показать на этом относительном подходе к их определению, что никогда нельзя просто рассматривать кого-то, как просто БА с конкретным набором навыков и опыта. Мы должны понимать, что уровни владения и виды навыков могут быть разные или простыми словами БА БА рознь. Я специально написал «относительном подходе», так как подход к разделению любой человек может выбрать собственный и это только один из вариантов. Один БА только-только начал писать качественный требования, а например, другой БА уже полностью управляется жизненным циклом требований для конкретного компонента, и он уже почти старший БА по факту.

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

«Навык» (или на английском Skill – Скилл) это приобретенная способность выполнять действия с определенным результатом с определенным качеством и в соответствии с определенными ожиданиями по время и трудозатратами. Под приобретенной способностью мы подразумеваем усвоенные практический опыт и специфичное знание, которые с учетом накопительного эффекта в нашей памяти трансформируются в структурированное хранилище алгоритмов или схем действий (не обязательно физических), которые мы эффективно применяем в соответствующей ситуации/контексте. Наличие приобретённой способности отражает обязательно наличие ожидаемого результата и уровня качества этого результата.

Существует несколько типов навыков. В контексте бизнес-анализа в основном мы используем два типа – Hard skills (жесткие навыки) и Soft skills (мягкие навыки).

Жесткие или технические навыки это навыки относящиеся к конкретным задачам(домену/области) в конкретной ситуации или контексте. Чаще всего такие навыки могут быть проверены и иметь определенные описанные требования, через которые может быть проверено мастерство/умение человека в этом навыке. Например, повар имеет основной жесткий навык «приготовление ресторанных блюд». Навык относится к области приготовление пищи в контексте/области ресторанов. Как мы знаем мастерство повара может быть проверено на качество. И навык этот приобретённый через получение знаний (изучение литературы/курсы и так далее), а также практический опыт (приготовление, приготовление и много раз приготовление разных блюд). Мягкие навыки – это навыки, отражающие наши личностное поведение или взаимодействие с другими людьми – они не привязаны к какой-либо специфичной задаче в вашей работе. Но они являются абсолютно необходимыми, для выполнения задач в любой деятельности – так как существенно влияют на успешность и качество выполняемых задач/активностей, где мы применяем жесткие навыки. Посмотрев на работу повара и его профессионализм в жестком навыке, я думаю повар в дополнение должен обязательно обладать несколькими мягкими навыками, без которых не будет успешен. Такими как «управление своим временем» (Time management) – ведь никто не будет ждать вместо 40 минут целых 4 часа для приготовления блюда. Или например, шеф-повар без высокого уровня мастерства в «лидерстве» и «коммуникации» навыков – вряд ли сможет наладить процесс приготовления блюд в ресторане со своей командой.

Уточнение от меня – описывая в следующих шагах навыки в контексте конкретного уровня/подуровня, я не в коем случае не говорю о них как о требованиях к этому уровню. Нет – указание этих навыков, это моя рекомендация в какой период времени, карьерного развития я рекомендую усвоить определенный навык. Каждый человек индивидуален как я уже упоминал – и развитие навыков происходит индивидуально тоже и в определенном контексте/обстановке.

Шаг 1 – начинающий БА

…на котором я получаю сразу же свой первый проект и разбираюсь с документированием требований под пристальным вниманием со стороны моего ментора (и он же ведущий БА на этом проекте).

Начнем там, где я закончил описание пути своего профессионального становления как БА в предыдущей истории. Итак, в марте 2013 года я устроился на должность БА в свою первую ИТ компанию НетКрекер, которая занимается разработкой ИТ продуктов для телекоммуникационных провайдеров. Меня сразу же подключили в команду, которая создавала для клиента многокомпонентную систему поддержки бизнеса клиента. Мой основной плюс был в знании и опыте (как конечный пользователь) по операционному домену – система управления взаимоотношениями с клиентами (customer relationship management). И поэтому я начал работать над соответствующим компонентом, под руководством ведущего БА, который уже занимался этим компонентом некоторое время. Мне это очень понравилось, что сразу же меня подключили к реальным задачам, хотя и у меня был нулевой опыт в бизнес-анализе. Так же в дополнение к задачам по проекту естественно мне предоставили множество ресурсов для изучения непосредственно самого продукта, который компания разрабатывала – из каких модулей и компонентов он состоял, какая архитектура использовалась и так далее. И кроме продукта, так же важно было изучить и знать телекоммуникационные стандарты разработки продуктов. У меня проходили каждый день утром созвоны с ведущим БА, который объяснял мне задачу, которую мне давал и так же предоставлял примеры уже аналогичных задач решенных, чтобы я мог делать по аналогии (один из главных подходов БА кстати – создавать что-либо в первую очередь по возможности на основании существующих артефактов/шаблонов). Если в процессе выполнения задачи возникали вопросы, то я их записывал и созванивался дополнительно, например, раз в день с БА и обсуждал их. Мы проверяли прогресс выполнения моих задач постоянно – иногда один-два раза в день или обязательно на следующий день. Это важный принцип, который я использую и сейчас через 10 лет каждый день в работе со своими коллегами. Принцип: никогда не жди финальный результат по задаче, чтобы проверить качество – обязательно нужно делать промежуточные проверки, чтобы заранее определить отклонение от ожидаемого результата, обсудить их и исправить. Чем позже будет обнаружено отклонение, тем дороже будет его исправлять. «Дороже» я имею в виду в любом измерении – деньги, время, ресурсы. Когда мы проверили, что я сделал, то мой БА давал мне комментарии и уточнения, что именно нужно исправить и почему. Например, он показывал уже готовый и подписанный (клиентом) артефакт и объяснял, почему именно так наиболее эффективно документировать. Чем же именно я занимался в первые дни/недели и как выглядел мой обычный рабочий день новичка БА?

Мой рабочий день разделялся на две основные активности – коммуникация с ведущим БА и работа с требованиями. Была еще третья дополнительная активность, которую я упоминал чуть выше – изучение систем/стандартов компании и продукта. Но ею я занимался очень немного времени и в основном только когда возникала какая-то реальная связь с теми проектными задачами, которые я выполнял. Я всегда пользуюсь одним и тем же подходом последние (и сейчас) десять лет в плане приоритизация между реальными задачами и получением новых знаний – я изучаю что-то новое только, если я на 100 процентов уверен, что все мои задачи уже готовы или будут готовы в нужные сроки.

Примерно в первые четыре недели я делал один и тот же тип задачи: документирование описания/дизайна небольших частей функциональных требований к системе. Я специально добавил словосочетание «небольших частей» – задача была именно описать небольшую часть какой-либо функциональности системы. Так как опыта у меня не было, то давать задачу на описание всей функциональности было бы очень неэффективно. И у нас с моим ведущим БА получалась отличная коллаборация – он примерно набрасывал/рассказывал основные части, которые у нас будут присутствовать в функции. Потом объяснял мне, что мы имеем на входе – бизнес и функциональные требования и что ожидается на выходе – дизайн требований, а также ожидаемый формат и уровень детализации.

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

Я прихожу на работу, думаю к часам 9 или к 10, или к 11. И эта гибкость и свобода в выборе рабочего времени – это один из удивительных и приятных плюсов работы в ИТ компании (по крайней мере, где работал я и на БА должности), после того, как покидаешь мир обычного бизнеса, где довольно часто тебя беспричинно просят обязательно быть ровно в 9 или раньше в офисе, даже если никаких срочных дел/совещаний нет. Да, в первые недели для меня это было довольно необычное ощущение, но по лично моей оценке это очень серьезно мотивирующий фактор для эффективной работы – рабочее время важно именно для выполнения задач в поставленный/определенный срок.

Первой задачей у меня всегда идет проверка моего ежедневника, где списком записаны все открытые задачи и их статус. Мониторинг и планирование задач – это мощнейший инструмент эффективной работы и тайм менеджмента (этой темы я буду касаться на протяжении всей книги, постепенно добавляя больше и больше деталей и ценностей). Я проверяю требующие внимания (открытые) и «в процессе» задачи в этом списке. Определяю какой займусь. Проверяю, не записаны ли у меня какие-либо препятствия/блокеры к выбранной задаче, которые не связаны со мной и требуют прояснения/действий от кого-либо еще. Если такие есть, то я планирую в большинстве случаев звонок с моим БА в свободное для него время. Я это делаю сразу, а не планирую это после того, как дойду до момента, когда мне уже нечего будет делать из-за блокирующих задач. Планирование звонков и основных активностей – это задача, на которую можно потратить 5-15 минут сразу и потом спокойно работать, имея назначенный нужный митинг (meeting – встреча, собрание проводимое в любом формате. По телефону, через интернет, вживую) в календаре.

Второй задачей/активностью у меня может быть звонок с моим ведущим БА ментором. «Может» – в контексте, что может быть утром или например, вечером. Как я писал выше – на начальных этапах очень важно синхронизировать формат, план, процесс и ожидания от своих активностей с тем, кто ответственен за весь результат. Мы проговариваем, что я сделал вчера, какие вопросы возникли и какие планы на сегодня. Собрав отзывы от БА, я приступаю к своим ежедневным активностям. Самый важный момент этого пункта, который я хочу подсветить – я рекомендую именно в первой половине дня (а лучше утром) иметь звонки/совещания с нужными людьми, чтобы с максимальной пользой усвоить полученную информацию. За 10 лет работы у меня сложилось устойчивое понимание (знание?) о природе человеческого мозга (и, по-моему, даже какие-то ученые делали похожее исследование) в контексте корреляции работы с информацией разной сложности восприятия и рабочим временем. Сложные мыслительные процессы или активности наиболее эффективно выполняются в ранние часы, когда человек только начинает работать. Чем больше времени человек провел в работе, тем хуже он воспринимает более сложную информацию и выполняет более сложные активности. Есть даже такое выражение «обсудим на свежую голову» – так как обсуждать что-то под конец дня не эффективно. Вот и в контексте моих двух основных активностей звонков с ведущим БА и документирования дизайна я старался следовать этому подходу. Воспринимать, обрабатывать/анализировать информацию от кого-либо и принимать решения в короткие промежутки времени во время звонков/совещаний естественно намного и намного сложнее, чем в одиночку выполнять создание и документирование информации по дизайну требований. Поэтому я старался иметь звонки по утрам, чтобы ничего не упустить и максимально эффективно решить все открытые вопросы, а потом уже заняться документированием. Если мозг к вечеру уже перегружен, то снизить нагрузку или закончить документирование – не составит труда. А вот взять и отменить митинг или придти на него, но провести его только с 70-60-50 процентной эффективностью – вот это уже негативно повлияет на цели активностей. Я привел пример естественно в контексте обычного дневного рабочего дня. Но суть та же и для людей, которые по каким-либо причинам работают с обеда и до поздней ночи.

Затем я начинаю документировать дизайн к функциональному требованию. Обязательно я использую шаблон описания, который я обсудил со своим ведущим БА. Здесь подсвечу важный пункт – наличие больше одного БА на проекте это большой и большой плюс для создания необходимых артефактов, так как такой плюс создает коллаборативный подход в разных БА активностях, который логично уменьшает количество ошибок и улучшает качество работы через внутренние БА обсуждения и договоренности по любым БА темам. Например, формат используемого шаблона для написания дизайна к требованиям. Перед тем как описывать, что такое «документирование дизайна функционального требования» думаю я опишу пока простым языком, что такое функциональное требование. Я не буду вдаваться в глубокие детали, так как по окончанию этого шага я как и в предыдущей истории, так же возьму место для подробного описания «технических» моментов о том, какие навыки и активности рекомендую осваивать при старте карьеры БА. Любая ИТ система (или приложение или программа) имеет функции – это определенное свойство системы, позволяющее удовлетворять (выполнять) запросы пользователя. Под «пользователем» в большинстве случаев мы подразумеваем живого человека, который работает с нашей системой. Бывают конечно такие специфичные технические проекты, где под «пользователем» мы так же рассматриваем систему или определенный модуль системы, который использует функции другой системой. Но пока не будем касаться этих сценариев. Когда пользователь взаимодействует с системой, то на его запросы/действия система реагирует определенным образом. И вот ожидания, как система должна реагировать на использование пользователем определенной функции этой системы и называется функциональным требованием. Так как сначала мы создаем систему, а уже потом пользователь начинает пользоваться системой и ее функциями – поэтому мы называем это функциональным требованием. Это именно требование к тому, как должна работать функция системы – иначе пользователю не будет нужна эта система, когда она будет доставлена ему, но не будет соответствовать функциональным требованиям. А теперь про документирование дизайна к функциональному требованию и опять небольшое разъяснение от меня, что я подразумеваю под «дизайном»: это описание, спецификация или план, который показывает, как должна работать/выполняться функция, чтобы соответствовать функциональному требованию. Интересный факт, что если вы на английском наберете вопрос «что значит слово дизайн» в поисковой системе в интернете, то основные общие определения этого слова будут упоминать эти два ключевых слова «план или спецификация» и «функция», даже без какой-либо связи с ИТ областью. Почему активность именно про документирование дизайна? – тут всё просто. Основная цель БА почти всегда подготовить документ/артефакт для команды разработчиков, чтобы они могли создать необходимую систему именно так, как ее планирует использовать пользователь. Наличие только функционального требования без дизайна не даст команде разработчиков необходимой информации о том, что именно нужно создать – по крайней мере в моей 10-летней практике я не видел такого. Хотя можно найти мнения в интернете, что например, при определенных «гибких» методологиях именно так и создаются продукты – разработчикам передается просто требование и они волшебным образом создают именно то, что нужно.

Сам процесс документирования дизайна может занимать разное время и объем. Одно требование может содержать дизайн в полстраницы формата А4 и занять 30 минут на написание. Дизайн другого может занять 10 страниц и неделю на написание. Так же есть разные форматы и подходы к дизайну, которые зависят от многих факторов, окружающего нас контекста. И вот эта активность и занимает примерно 80 процентов моего дневного рабочего времени в эти дни и недели. Документировал я дизайн простейшим и надежным способом – в обычном текстовом (MS Word) документе/файле. Никаких специальных дополнительных программ. Этот документ был в онлайн (online) доступе у моего ментора – он проверял мои дизайны и оставлял комментарии в файле, которые я проверял и делал правки. Непрерывный процесс документирования, комментариев от ментора и соответствующих обновлений от меня. Самое приятное в этом процессе было наблюдать, как количество комментариев с течением времени (дней/недель) уменьшается и уменьшается, отражая обратную прямолинейную зависимость к росту качества моей работы. Еще раз повторю про плюс работе в команде и особенно с ведущими БА на старте карьеры – когда ты доверяешь профессионализму своего коллеги, то определить и наблюдать за улучшением своих личных показателей качества становится очень легко, даже не читая сотни страниц книг и статей на тему «ключевые показатели продуктивности».

Скучно ли это создавать дизайн требований с утра до вечера неделями? Для меня это было фантастически интересно так как а) я создавал! – это один из главных двигателей и критериев моей удовлетворенности моей работой (я буду часто это повторять через книгу). Тот факт, что ты что-то создаешь – очень приятен! Главное прослеживать, пусть даже просто в своем воображении, цепочку связей между своей деятельностью и финальным итогом. Если я просто описал обычную кнопку, которая активирует что-то в системе -> я визуализирую это в глобальных масштабах так сказать – когда мою кнопку разработчики создадут в системе, которую потом протестируют и запустят для клиента, который предоставит эту систему в пользование своим пользователям, то пользователи/продавцы в магазине будут проводить покупки для клиентов, с помощью функции, созданной по моему дизайну. Пусть это ИТ система/приложение/программа, но почти в 99 процентах случаев программы нужны для внедрения в бизнес-процессы, а значит в повседневную жизнь кого-то. Значит кому-то я улучшил/упростил работу. б) наличие ментора/команды позволяет оттачивать своё мастерство каждый день – любой человек по своей натуре всегда старается найти причину и дать полезный комментарий к любой активности другого, когда его об этом просят. Если конечно только ему не лень и без разницы, но таких людей к себе в менторы лучше не записывать. Так о чём я? – о том, что каждый день написание дизайна не может быть одинаково, когда у вас есть комментарии от кого-то, а значит пункты к улучшениям. Не всегда комментарии могут понравиться (по факту они почти никогда не нравятся), но также одна из основных задач и черт хорошего БА это научится воспринимать эффективно критику, комментарии, отзывы и рекомендации к улучшению чего-либо. Под «эффективно» я подразумеваю: в первую очередь внимательно выслушать, потом проанализировать, применить к своей ситуации и принять решение – улучшит ли что-либо предложение, сделанное кем-либо. Моё внутреннее ощущение, что 70-80% рекомендаций, которые я получил за весь период мне помогли улучшить качество выполнения задач. Причем довольно часто сами комментарии могли не иметь прямого влияния на улучшение, но вот их анализ и применение к ситуации – именно сами действия помогали выявить совершенно другие «дыры» в создаваемом решении, на которые без этих комментариев я бы никогда не обратил внимания. Простой пример: я создаю небольшое описание реакции системы на нажатие кнопки пользователем. Потом коллега просматривает этот дизайн и оставляет комментарий «мне кажется выполнение открытия дополнительного поля по нажатию на кнопку должно быть описано отдельные сценарием». Так как функциональность кнопки минимальна я считаю, что разделять описание не надо, но я проверяю, что я написал. И нахожу важный «пробел» в описании функциональности кнопки – я не описал как должна работать кнопка при ее повторном нажатии. Отзыв в любом случае оказался очень полезным. в) в любой активности можно искать возможности улучшений и улучшения эти можно придумывать бесконечно в самой простой (такая существует???) активности/работе. Улучшения, которые будут по факту изменять кажущуюся однообразность работы и дней. Один из самых простых и эффективных мотиваторов к улучшениям, который я использую через всю свою карьеру очень прост. Следовать главному принципу любого развития (личностного, физического, профессионального и так далее) – закончив день спроси себя «а что я сегодня сделал лучше/эффективнее, чем вчера?» Если ответ есть, то мы развиваемся. Конечно, каждый день делать улучшения может быть сложно, поэтому периоды сравнений могут варьироваться. Но если вы не сравниваете результаты своего труда с предыдущими – то, как вы поймете, что что-то улучшается или может даже ухудшается в вашей экспертизе? И еще у этого мотиватора я обожаю факт того, что он всегда имеет психологическое влияние на ваше общее состояние по итогам проверки улучшений – если это окончание задачи, дня, недели, когда вы завершили какую-то активность и видите что создан артефакт следующего уровня качества (пусть даже всего лишь немного лучше) по сравнению с предыдущим, то это дает позитивный настрой, энергию на весь оставшийся день и на начало следующего дня/недели/месяца. Ну во всяком случае у меня это так – может я чрезмерно оптимистичен.

Я кратко рассказал про свои рабочие будни, но, наверное, у многих читателей возник вопрос во время прочтения «а что по поводу самих требований? Рассказал немного про дизайн, а про требования ничего». Я выбрал хронологический порядок как он был на самом деле, так как мой контекст работы на начальных этапах подразумевал основной акцент именно на изучение и получения опыта в дизайне требований.

И немного про изучение требований и как я с ними работал. Требованиями я занимался как дополнительной активностью – усваивал, что это и как они создаются. Изначально требования я получал уже готовые в формате списка от моего ведущего БА. Я изучал документ с требованиями, которые он подготовил, потом документ проверил и подписал клиент, и возможно ведущий БА их дополнительно декомпозировал (разделял еще на несколько). У нас было два типа требований – функциональные и бизнес. Это и сейчас для меня является самым простым, логичным и последовательным разделением. Сначала идут бизнес требования к системе, которые формируются клиентом. Чаще всего, по факту, их создает БА в тесном взаимодействии с клиентом. Эти требования определяют границы решения, которое хочет клиент. Эти требования исходя из названия – это то что хочет бизнес. НО! Это всё-таки требования именно к системе, а не к бизнес-процессами или к определенной деятельности клиента. Обычно бизнес-требование – это одно предложение, написанное понятным для бизнес-клиента языком и в то же время, определяющее ожидания от системы. Например, «Должна быть возможность хранить информацию о клиентах» или «Оплата заказа в системе должна поддерживать оплату пластиковыми картами и с банковского счета». Мы видим здесь описание желания (по факту требования) бизнеса без каких-либо деталей о том, что, как и где. Но бизнесу/клиенту ведь важно именно это – поэтому длинный список таких требований создается и подписывается с клиентом, чтобы он был 100 процентов уверен, что это будет сделано. Все остальные детали попадают в функциональные требования. Функциональные требования, в данном контексте, были декомпозицией бизнес-требований. Они необходимы, чтобы уже с нужной точностью и детализацией определить, что же именно (какие функции) должна поддерживать система. Те функциональные требования, которые я изучал, выглядели как одно, максимум два предложения. Например, для бизнеса требования о возможности управления информацией о клиентах могло подготавливаться 100-200 функциональных требований. Одно из них могло звучать как «Система должна предоставлять пользователю возможность создать профиль клиента», другое «Система должна поддерживать в профиле клиента 10 следующих параметров о клиенте:….» И так далее. Из таких требований было однозначно понятно поддержка какой функции ожидается – Например, функция создания профиля пользователя. И это функциональное требование так же просматривалось с клиентом и подписывалось им. Потом вот такое требование попадало ко мне, и я создавал дизайн, как именно будет реализовано создание профиля клиента. Важно упомянуть что все бизнес-требования и функциональные требования были связаны между собой в отдельном документе, который назывался матрицей прослеживаемости/взаимосвязей (Traceability Matrix). Документ помогал быть уверенным, что все созданные функциональные требования действительно нужны и связаны с бизнес-требованием и наоборот, что все бизнес-требования имеют функциональную реализацию. Так как мы создавали серьезные большие системы для поддержки бизнеса телекоммуникационных компаний – только для одного модуля/компонента «система управления клиентами» могло быть создано 400-500 функциональных требований. При таких объемах информации с требованиями, создание документа, который хранит все связи между требованиями, было абсолютно необходимо. И были такие ситуации, когда именно этот документ помогал находить несоответствия в связях и избавляться даже просто от лишней ненужной работы – Например, когда находилось функциональное требование, которое по факту не было связано не с каким бизнес-требованием (и соответственно не было более актуальным). Или возможно бизнес-требование изменилось или было удалено по итогам недавних обсуждений с клиентом. Потихоньку я начал заниматься и сам написанием функциональных требований к новым появляющимся бизнес-требованиям, так как за 3-4 недели уже разобрался, как выглядит бизнес-требование, потом функциональное требование и как оно превращается в дизайн.

Про свои активности в течение рабочего дня я кратко рассказал, а теперь немного в другой плоскости хотел бы посмотреть на это и рассказать про непосредственно сами артефакты и конкретный пример, как из одного бизнес требования я создавал функциональное требования и потом документировал дизайн для этого требования и из каких частей состоял этот дизайн. Естественно, примеры ниже это выдуманные примеры, которые я создал для визуализации – описание бизнес и функциональных требований не содержат и не раскрывают никакой коммерческой информации. Мои личные ощущения сейчас – то, как я создавал функциональное требование и потом дизайн к нему по своей «природе»/структуре не сильно отличается от того, как я делаю это сейчас. Изменились инструменты, немного формат и терминология (стала более модная), но сама смысловая нагрузка, подход и акцент остались те же. Если бы сейчас я попал на проект с тем же проектным контекстом, методологией и условиями, то вполне вероятно я бы пошел тем же путем к созданию и написанию требований/дизайна, как и 10 лет назад. Итак, я уже работаю полтора-два месяца, как БА в моей первой ИТ компании и я уже начинаю создавать/писать сам функциональные требования для новых компонентов/модулей системы. В плане «новых» главная ценность для меня это то, что на меня также стала распространяться ответственность за создание требований на основании существующих бизнес-требований, которые заранее все уже подготовлены и подписаны с клиентом на все новые компоненты. У меня появляется задача создать функциональное требование и дизайн к нему.

Создание требований

Есть бизнес-требование, которое звучит как «Профиль компании должен содержать информацию о кредитоспособности компании» – то есть требование от бизнеса и клиента довольно прозрачно. При любых коммерческих, торговых операциях между компаниями, компания продавец при предоставлении товаров в рассрочку, должна проверять и быть уверенной в платежеспособности компании-покупателя. Для данного бизнес-требования я, возможно, напишу 10-20 функциональных требований, но здесь опишу только одно.

На основании данного бизнес-требования я создаю функциональное требование «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента включая следующую информацию: кредитный статус, кредитный рейтинг, текущие кредитные условия». Что это за «ФТ-СУК-КР-1»? Это уникальный идентификатор требования, который в дальнейшем будет использоваться для матрицы связей/отслеживания и для упоминания в любых других связанных с этим требованием документах. Так же правила создания идентификатора создаются таким образом, чтобы, зная их можно было легко определить, о чем это требование. «ФТ» – значит Функциональное Требование. «СУК» – название системы куда входит требование «Система Управления Клиентами». «КР» – название модуля/компонента внутри системы «Кредитный модуль». И конечно же номер требования. Текстовка требования может изменяться, но идентификатор – никогда. Само требование состоит из следующих важных пунктов: 1) «Система» – это простое, но важное слово, которое 100 процентов подтверждает, что именно наша система должна поддержать определенную функциональность. 2) «должна» – тоже ключевое слово в требовании, которое очень явно говорит, что система именно «должна» поддержать функциональность, а не «может» или «будет» предоставлять что-то. Это важно – всего одно предложение, но оно может стоить десятки тысяч долларов например, и малейшая неясность в написании может быть использована как заказчиком, так и исполнителем. Например, использование словосочетания «Система может…» – может трактоваться как не обязательная часть функциональности системы и читаться как «ну может система будет выполнять такую-то функцию, а возможно и не может». 3) «предоставлять информацию на странице…» – описываем «местоположение» и «что», чтобы точно определить, где будет находиться функция. 4) «следующую информацию:…» и в заключение я определяю какую точно информацию мы должны предоставлять, а именно какие параметры. Есть вероятность, что какие-то еще параметры будут добавлены или нет, если это будет доступно с точки зрения проектного контекста. Но вот эти три упомянутых параметры точно будут присутствовать. Ну вот функциональное требование и готово! Возможно, у вас возник вопрос «а откуда и как ты всего лишь на основании короткого и общего бизнес-требования решил написать такое функциональное требование? Откуда детали про где и что?». Первая часть ответа – понимание как, где и что частично появляется у меня как раз на основании моего доменного опыта, о котором я упоминал ранее в этой книге. Я много лет работал в бизнесе и был именно конечным пользователем множества бизнес-систем, которые почти всегда содержат примерно одинаковый набор параметров и функций (и как я говорил, это был один из критериев, по которым меня рассматривали на эту работу без ИТ опыта). Соответственно в нашей системе для клиента я предлагаю наиболее распространенный подход в данном случае к информации о платежо/кредитоспособности клиента. Вторая часть ответа – именно сейчас я описываю исключительно действия, связанные с документированием требований. На самом деле, естественно, существуют еще коммуникационные действия – такие, как обсуждение требований, обновлений требований и их подписание. Т.е. для моего только что написанного функционального требования я НЕ начну тут же документировать дизайн. Сначала будет внутреннее рассмотрение с моим ведущим БА, возможные правки, а потом будет обсуждение с клиентом и возможные правки от него и потом подписание требования. И только потом в я начинаю документировать дизайн к этому функциональному требованию.

Дизайн требования

И вот пропустив несколько процессных шагов (пока) в данной истории и получив подписанное функциональное требование я сажусь за написание/создание дизайна к этому требованию. Описываю я функциональный дизайн в документе, который называется Спецификация по функциональному дизайну (Functional Design Specification). Уточнение – то, что я описываю ниже (да и выше) не является общей лучшей-практикой, которую я очень рекомендую здесь, нет. Любой подход к написанию требований зависит от окружающего контекста.

С чего я начинаю, имея функциональное требование в одно предложение? Сначала я создаю еще один уникальный идентификатор, но теперь уже для дизайна ФД-СУК-КР-1. Расшифровка та же кроме первой части, где я меняю ФТ на ФД, что соответственно значит «Функциональный Дизайн». Затем я создаю короткое название дизайна, чтобы его можно было использовать как заголовок. Например, «Просмотр кредитной информации на главной странице компании». Функциональное требование может быть связано только с одним дизайном, а может быть связано и с несколькими. Я печатаю наверху документа ФД-СУК-КР-1 «Просмотр кредитной информации на главной странице компании».

Теперь можно написать краткое и простым языком описание, о чем будет этот дизайн и для этого у меня есть раздел, который так и называется «Описание». Прочитав этот раздел, любой человек клиент, разработчик, проектный менеджер и кто угодно – сможет понять, в чем смысл этого дизайна и о чем это.

“Описание: данный дизайн/функциональность предоставляет возможность пользователю увидеть основные кредитные показатели компании-клиента на главной странице профиля клиента. Эта информация поможет пользователю в принятии решений”.

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

Затем я описываю что же именно – какую функциональность получит пользователь. Обычно я пишу нумерованным списком в логической последовательности шаги, как ведет себя система при определенном варианте/сценарии ее использования – так легче структурировать цепочку действий и в дальнейшем обсуждать любые комментарии («а вот в шаге/пункте 4 у тебя мне кажется нужно …»).

Шаги/Сценарий:

На странице профиля компании система отображает раздел «кредитная информация».

В разделе «кредитная информация» отображаются следующие поля/данные:

«Кредитный рейтинг» название- текстовое, неизменяемое.

Кредитный рейтинг значение – неизменяемое, цифровое, двузначное, с поддержкой десятичного значения, диапазон значений: от 0 до 10.

«Кредитный статус» название – текстовое, неизменяемое.

Кредитный статус значение – неизменяемое, графическое отображение «круг» с тремя вариантами красный/желтый/зеленый.

«Кредитные условия» название – текстовое, неизменяемое.

Кредитные условия значение – неизменяемые три текстовых поля со «значениями»: а) разрешенная рассрочка: «ХХ» месяцев б) статус контракта: «активен»/«неактивен»/«истек» в) размер задолженности: «нет» / «размер задолженности».

«Кредитная история» название – текстовое, неизменяемое, формат ссылки (функциональность вне границ этого дизайна – ФД-СУК-КР-4 идентификатор дизайна с описанием).

Вот и всё – это и есть описание основного блока дизайна. Естественно, я специально взял наиболее простую функциональность, чтобы не потратить 10-20 страниц только на описание дизайна.

После описания сценария я добавляю еще раздел «Изменение данных» – в данном дизайне он будет пуст или я укажу «изменений данных не предусмотрено», так как у пользователя нет возможности изменить какие-либо данные для данной функциональности.

Функциональный дизайн готов к использованию разработчиками! Но это еще не всё – в большинстве случаев функциональность для пользователя должна «идти» вместе визуальной и дата составляющими. Ведь кроме понимания, как должна быть реализована функциональность, команде разработчиков так же надо знать, как эта функциональность будет выглядеть и откуда будут поступать необходимые динамические данные для этой визуализации. Для этих целей я создаю еще два документа – Спецификацию по пользовательскому интерфейсу (СПИ/ User Interface Specification) и Спецификация по модели данных(СМД/ Data Model Specification). Эти два документа являются тоже частью дизайна требования. СПИ содержит дизайн макеты, как будет визуально выглядеть раздел кредитная история для пользователя. А СМД содержит описание, где будут храниться данные, которые я описал в функциональном дизайне. Почему визуальная составляющая хранилась в отдельном документе? На тот момент я не обладал достаточным опытом, чтобы изменить подход, но вот сейчас я предпочитаю самый оптимальный подход это описание и функциональной части и визуальной в одном месте – это даёт любому пользователю артефакта сразу понятную картину, что, как и где должно работать. А вот модель данных должна на мой взгляд создаваться отдельно и не может быть представлена кусками в каждом функциональном дизайне. Цель документирование всей модели данных в одном месте это визуализировать и дать полную картину именно о модели данных и о ее корректности и логичности и связей между всеми объектами и атрибутами и их свойствами. Не буду углубляться сейчас, так как вернемся к этому позже в следующих шагах в деталях.

Мы рассмотрели одно очень простое функциональное требование и функциональный дизайн. Как я упомянул, начинал я дизайн после того, требование было проверено ведущим БА и потом с его помощью подписано клиентом. Но когда дизайн был готов, то, естественно, я не мог отдать дизайн команде разработчиков, чтобы они начали создавать эту часть системы. Не мог, потому что опять же дизайн требовал проверки/валидации от БА, с которым я работал. Он мог указать на упущенные нюансы/моменты, которые нужно поправить. И когда вся функциональная спецификация была готова мы ее отдавали клиенту на проверку.

Вот собственно, что я хотел рассказать про реальные первые месяцы моей работы бизнес-аналитиком. Я не общался с клиентом и не занимался выявлением бизнес или функциональных требований – этих обязанностей у меня не было, так как и опыта не было и нужно было сначала изучить базовые активности. Я даже не знал, какой используется и из чего состоит цикл разработки программы/системы. А использовали мы методологию разработки, которая называется «Водопад» (Waterfall). Почему «Водопад»? – потому что создание системы/продукта поделено на этапы, которые всегда выполняются в последовательном порядке – один за другим. Отсутствие этих навыков и знаний – было ли это плохо или негативно в плане моего опыта? На мой взгляд нет, так как я получал полноценный опыт в самом базовом и необходимом БА навыке – документирование требований и их дизайна. То, что я описывал выше, как вы поняли это «жесткие» навыки (Hard skills). А вот какие из «мягких» навыков (Soft skills) я бы подсветил, в которых я получал(развивал?) опыт и считал важными? Думаю, я стартовал три основных мягких навыка, которые я назову в формате ролей: командный игрок, мистер-вопрошайка и тайм-менеджер. Уточню, что некоторые приобретенные способности, которые я называю «мягкими» навыками выше, не являются прямо официальными навыками, которые указаны в книгах ну или может они указаны, но в других терминах. Я написал именно «стартовал», так как все эти три навыка я продолжал развивать на протяжении своей БА карьеры. Расскажу кратко о них и почему именно они мне показались (или нет) важны на старте:

Командный игрок

Я начинал свою карьеру в команде, состоящей всего лишь из меня и ведущего БА, но это уже была команда! Эффективная команда это залог/критерий успешного достижения любых целей в любой активности (и не только в ИТ сфере естественно). А один из критериев «эффективной» (продуктивной, быстрой, ценной, и так далее) команды является ситуация, когда в ней все участники являются командными игроками. Иначе команду нельзя назвать командой. Кто такой «командный игрок», как человек в плане работы? – для меня это человек/коллега, который:

–понимает и знает (да! – у командного игрока есть обязанность «понимать и знать») командные: цели, проблемы, планы, подходы к работе.

–умеет/обладает способностями: принимать решения вместе(командой), воспринимать любые отзывы/критику от команды позитивно и использовать ее для своего профессионального улучшения и для достижения целей команды, оценивать и принимать подход к распределению задач рационально с точки зрения эффективности для всей команды, быть честным и открытым для команды, даже при обнаружении проблем созданных самим собой, постоянно стремиться к улучшению процессов в команде, слушать команду, соблюдает авторитет Ведущего команды (ведь именно он в итоге ответственен за команду перед всеми «выше» стоящими) и последнее простое, но очень важное – уважать свою команду в любых плоскостях (Например, никогда не опаздывает на встречи или если не успевает, то предупреждает).

Почему этот «мягкий» навык я включаю в начальный список? Я думаю, на любом этапе профессионального развития человек должен стараться приобретать те навыки, которые наиболее актуальны в конкретный момент времени этап развития. Когда только начинаешь БА путь, то почти нет жестких навыков, которыми ты можешь «выделиться» и помочь команде или проекту. И команда (проектная или БА) может в основном оценивать тебя именно по мягким навыками, которые в свою очередь могут существенно ускорить и улучшить приобретение жестких навыков. И так как я уже упомянул слово «команда», то становится логичным, что первый и ключевой навык должен быть связан с командой. И не может быть сценария, когда у БА нет команды – так как процесса создания продукта или проекта не бывает без команды. И соответственно БА, который есть хороший (а лучше «отличный») командный игрок – это то, на что команда будет смотреть в первую очередь. Команда может сказать «да этот БА еще новичок и не очень разбирается в БА специфике, но он отличный командный игрок – мы им довольны».

Почемучка

В силу специфики работы БА этот навык просто обязателен с самого начала карьеры. Вся наша работа связана с получением информации из каких-либо источников, трансформацией информации и передачей информации. И естественно первый пункт важен здесь, так как он первый и в другой последовательности эти пункты поставить нельзя. Сначала информацию нужно получить. Получение информации в БА работе один из ключевых и непрерывно повторяющихся процессов. В процессе «Получить информацию» конечно же есть пункт/активность «выслушать и записать» и еще много других активностей. И так же важнейшая активность «задавать вопросы», без которой любая полученная информация может быть некорректной, неверной, недостаточной, неполной, да и вообще бесполезной. Что тут говорить – активность «задавать вопросы» это ключевой навык во всем жизненном цикле любого человека. По крайней мере точно в первые несколько лет жизни, начиная с рождения. Ведь через вопросы ребенок познает и изучает мир (и сначала даже задавая вопросы без слов – жестами и звуками ). Если вы становитесь БА, то необходимо, так сказать, вернуться в детство и воспринимать эту активность, как обязательную часть работы! У вас никогда не получится создать требование, дизайн и как итоге продукт высокого качества, если, например, к вам придет человек и скажет «я хочу зеленую кнопку в этой программе» и после этого вы просто напишите требование и дизайн для своей команды состоящее из одного предложения «клиент хочет зеленую кнопку». Можно сказать, что именно вопросы создают востребованные решения/продукты. Что именно на мой взгляд включает в себя это навык «Почемучка»? На мой взгляд БА должен уметь/обладать способностями: задавать вопрос вовремя, задавать правильно сформулированный и/или визуализированный вопрос, определять и вовлекать нужную целевую аудиторию для получения информации, определять как ценность/важность вопроса, так и ценность полученной информации, и конечно же самое важное(!) не бояться задавать вопросы, даже если они кажутся слишком простыми или само собой разумеющимися или даже глупыми. Я предположу, что те пункты, которые я написал, выше кажутся по прочтении очень простыми, но это только кажется – за свою карьеру я видел достаточно реальных примеров, когда 4-6 месяцев работы целой команды могли быть потрачены в итоге впустую из-за одного вопроса, не заданного вовремя или заданного, но не правильного и не тем людям. И это именно навык, что значит приобретенная способность + знания – это не просто в чистом виде способность человека задать вопрос (да – мы все можем задавать вопросы и для этого нужен только рот, язык, выдох и желание сказать что-либо в вопросительной форме). Например, один из эффективных и помогающих сформировать правильную информацию вопросов является следующий вопрос прямым текстом «А зачем нам это надо?» Но в большинстве случаев, например, при получении информации от представителей клиента такой вопрос может сразу и серьезно испортить отношения с клиентом и соответственно прогресс проекта. И в этом сценарии и должна проявиться специфика навыка – задать этот простой вопрос в правильной формулировке и в нужное время, и для правильной аудитории.

Управленец временем

Вот и последний из упомянутых «мягкий» навык – тайм менеджмент или управление временем. Этот навык особенно важен и сложен для БА и поэтому что и логично начинать развивать его надо, как только началась карьера. В чем специфика или что есть этот навык простыми словами? Я бы описал так: умение человека в определенной обстановке (работа Например,) и при определенном контексте (проектном, продуктовом, коммуникативном, командном и так далее) выполнять свои задачи (активности, процессы, артефакты) максимально эффективно с точки зрения распределения времени на задачи, которые у него есть и должны быть выполнены. Расшифровка ключевой фразы «максимально эффективно» – когда на все задачи затрачивается минимально возможное время с получением максимально возможной пользы/ценности от их выполнения с максимально возможным качеством. «Минимизация время-затрат» как показатель эффективности участвует думаю во всех сферах труда и личной жизни. Простой пример применения тайм-менеджмент навыка в личной жизни (многие так делают я уверен?) – Например, каждый день дома я убираю со стола посуду в посудомойку. В среднем 6 тарелок. Если я отношу каждую тарелку на кухню в посудомойку, то это занимает примерно 6 секунд на каждую и 36 секунд на все тарелки. Если посчитать обед завтрак и ужин, то это 108 секунд в день. Округлим до 2 минут для простоты. Значит в месяц это 60 минут или 1 час. В год это 12 часов на уборку тарелок в посудомойку. А если я немного изменю процесс и все тарелки буду ставить на поднос или друг на друга и относить одним разом на кухню, то это займет не 36 секунд, а в три раза меньше времени – допустим около 12 секунд. Соответственно, при годовом расчёте можем уменьшить первоначальные 12 часов в три раза, то есть 4 часа и тогда 8 часов мы сэкономим. Таким образом у нас есть 8 часов в год, которые я гипотетически могу потратить куда хочу. В этом примере главное это то, что в большинстве случаев время имеет гибкость и всё зависит от того, как человек планирует своё время. Нужно планировать – это важно. Одна из ключевых частей управления временем это его планирование. Планирование времени – это планирование на задачи – ежедневные, еженедельные, ежемесячные и так далее. Наша жизнь состоит из постоянных задач и от того, как мы планируем задачи обязательные – зависит сколько у нас свободного времени будет на задачи необязательные (отдых). Естественно желательно, чтобы времени на отдых было как можно больше. В плане работы, когда я начал свою работу как БА, то я определил несколько целей, почему я делаю детально планирование задач: а) чтобы выполнять задачи вовремя в соответствии с поставленными сроками б) как следующий этап развития, чтобы по возможности выполнять задачи быстрее поставленных сроков в) чтобы как я уже упомянул высвобождать больше времени на необязательные задачи. Небольшое, но интересное уточнение/пояснение по поводу пункта «б» – это реальная цель, которую я всегда преследую и сейчас. Не просто выполнить задачу вовремя, а так запланировать свой день/неделю, чтобы выполнить задачу быстрее и желательно существенно быстрее. Когда я начал карьеру БА, я подумал «а чем я могу выделиться из команды остальных БА, которые работают у нас в компании?» и одним из существенных отличий я выбрал именно этот навык и подход к планированию. И я проверял довольно легко, что я развиваю этот навык. Работая уже несколько месяцев как БА и продолжая улучшать себя, я помню были ситуации, когда ведущий БА давал мне задачу по документированию требования и говорил «эту задачу нужно закончить примерно через 2 недели». Я делал планирование и подтверждал ему, что закончу задачу через 5 дней. Это была моя цель. И развитие этого навыка было прямо-пропорционально росту моей ценности в компании. В будущем возникали часто ситуации, когда именно я соглашался подключиться на «горящий» проект, где сроки были очень сжаты и для меня такой проектный контекст рассматривался как плюс. В деталях я думаю коснусь этих ситуаций в следующих главах. Возвращаясь к управлению временем, и почему этот навык важен и сложен добавлю, что эти два очень тесно переплетающихся термина, так как он сложен из-за важности и важен из-за сложности на мой взгляд. Сложен навык, так как работа БА не имеет однообразных четко определенных процессов по факту – каждый проект/продукт индивидуален и БА готовит соответствующие БА подходы. Под каждый проект и продукт нужно управлять временем соответствующе. БА должен уметь понимать контекст и управлять своим временем эффективно. Под «важен» я здесь подразумеваю высокую ценность и приоритет этого навыка и активностей, связанных с ним. Как пример сложности и важности вернусь опять к пункту «планирование времени/задач» – для меня это до сих самая важная и самая сложная ежедневная задача. Пока я не запланирую свой день – я не начинаю выполнять задачи. Я могу потратить иногда даже 30-60 или даже 90 минут просто на идентификацию, анализ, подготовку и планирование задач на день (с приоритезацией и декомпозицией). Зато когда планирование завершено и я знаю, что я выбрал и построил максимально эффективно свое рабочее время/день – > после этого мне легко и прозрачно выполнять все запланированные задачи без какого-либо сомнения. Детали, рекомендации и подходы мы рассмотрим в следующих главах. Может немного сумбурно, но вот так я размышляю о навыке управления временем. Остался только один пункт без которого описание навыка нельзя считать завершенным – это описание, что должен уметь/какими способностями обладать человек (на мой взгляд) и везде с приставкой «максимально эффективно» в отношении активностей/задач/процессов: делать планирование, приоритизировать, декомпозировать/дробить, распределять/определять время выполнения, быть сфокусированным, делегировать, всегда видеть целевую цепочку, принимать решения. Кратко о каждом умении. Планирование – это начало любой активности в общем и включает в себя такие пункты как определение самого процесса и подхода к планированию в зависимости от контекста, разработка артефактов планирования и их документирование, непрерывный мониторинг, валидация и актуализация плана. Непрерывная приоритизация активностей обеспечивает понимание и уверенность в том, что выполнение чего-либо происходит с максимально эффективным использованием времени и ценностью для конечных целей. Приоритеты могут меняться с течением времени или быть статичными, но их правильный порядок и четко определенные критерии для приоритетов должны быть определены. При прозрачном приоритезированном списке активностей/задач исключаются факторы сомнения о затрачиваемом времени на задачу – это важно психологически и профессионально, что когда я выполняю какую-либо задачу, то у меня нету даже малейшей мысли сомнения «а точно ли я сейчас должен этим заниматься и это поможет/полезно?». Декомпозиция очень важна и особенно по мере вашего профессионального роста и соответственно сложности в целом проектов/продуктов, где вы участвуете. Неправильная или недостаточная декомпозиция может привести к печальным и длинным задержкам в выполнении задач и, соответственно, достаточно неэффективном использовании времени. Не могу удержаться и не привести пример, который я думаю, большинство из вас сталкивалось в рабочих и не только активностях. Вот пример из внерабочих активностей, основанный на реальных событиях: скоро день рождение у моей жены и у меня есть активность «Поздравить с днем рождения». Для этой активности естественно есть или очень простой план без какой-либо декомпозиции, который выглядит как «Поздравить с днем рождения = купить подарок» и готово ИЛИ подумать и сделать декомпозицию, например, на три пункта: 1. Подготовить поздравление 2. Подготовить подарок. 3. Определить локации дня рождения. Эти три пункта в свою очередь содержат еще подпункты. И например, пункт №1 содержит мало ясности и соответственно временные рамки непонятны – можно начать делать его просто в формате «плыть по течению» – то есть, например, сесть и взять лист бумаги и начать писать поздравление или найти открытку в магазине и купить ее сразу. Или еще что-то и на это уйдет время, а личного удовольствия не будет от затраченного времени. Вместо этого этот пункт я разобью еще на подпункты: 1. придумать сценарий поздравления 2. Закупить необходимые материалы. З. Подготовить части поздравления. И эти три пункта декомпозировать так же – Например, пункт №2 я декомпозирую на еще подпункты: 1. материалы для подготовки видеопоздравления 2. материалы для стола. 3. Контекстные материалы. Из этих я еще сделаю разделение, например, пункта 3 на: надувные шары, фотографии на стену, коробки для подарков, упаковочная бумага и так далее. И вот после всех уровней декомпозиции у меня есть довольно простые задачи, которые я могу запланировать выполнить в уже примерно понятный временной срок и дату. Да – тут нет ничего сверхъестественного и всё просто – и в это простоте декомпозиции и есть сверхэффективность – декомпозиция позволяет концентрироваться на конкретной, понятной и выполнимой в краткосрочных рамках задаче/активности. Следующее умение про распределение и определение времени, выделяемого на что-либо – думаю тут не требуется объяснения, так как в большинстве случаев глобальная активность/цель всегда имеет временные рамки. Соответственно, любые ваши действия, чтобы рассматривать как эффективные с точки зрения времени, должны быть оценены – сколько времени они займут и когда наиболее правильно будет их выполнить. С «быть сфокусированным» тоже всё просто и важно – включая упомянутые выше умения про приоритезацию, планирование и декомпозицию у вас должна быть ясная картина, чем и когда заниматься и вот дальше уже важна личностная способность а) быть сфокусированным на именно одной задаче (никакого мультитаскинга/многозадачности) в единый момент времени и б) иметь всегда в фокусе всю картину о глобальной цели, когда вы тратите своё время на конкретную активность. Следующая способность «делегирование» подразумевает что вы понимаете и распределяете задачи на кого-либо с четким пониманием, какую пользу это приведет в контексте время-затрат и ценности для конечных целей. Если вы работаете в команде БА, то не должно быть сценариев, когда вы стараетесь все важные и сложные или большие задачи забрать себе – ведь у вас так же есть умение декомпозиции, которое может помочь распределить задачи внутри команды. Так же у вас обязательно будут активности которые будут иметь зависимости внутренние и внешние – у вас должно быть понимание и подход в каком формате, как, зачем и с какими ожиданиями делегировать что-либо на кого-либо. «Видеть целевую цепочку» – наверное прозрачное и понятное определение и оно требует просто наработки практическим опытом. Я бы описал его так и возможно это похоже на «быть сфокусированным» – в любом момент времени и в любых планах должна быть понятна (лично мне) связь от начала до конца всех целей и цепочки от цели маленькой активности до глобальной конечной цели. Если я делаю изменение одного поля на какой-то странице вебсайта, то я понимаю в целом, как это повлияет на один из бизнес-процессов, в котором используется вебсайт по продаже чего-либо, который создает наша команда. И последнее умение, которое звучит фантастически просто – уметь принимать решения. Да, да – это умение напрямую влияет на эффективное использование времени. Не должно быть колебаний в принятии любых решений. Это особенно просто, если всегда в голове «держать» и повторять себе, если вы не хотите/оттягиваете принятие какого-либо решения в данный момент (что в свою очередь и ведет как раз к не эффективному время использованию – задержкам) – я внутри напоминаю себе «в принятии решения всегда есть только опции, из которых надо выбрать. С любой опцией я двинусь дальше. Если что-то пойдет не так, то потом придется принять еще одно решение и это нормально.» Как-то так. Но не должно быть сценария, когда мы говорим «я не могу пока принять решение», тем более, если все умения/способности перечисленные выше уже применены и использованы. Применение описанного выше, как раз минимизирует любые сомнения. Вот теперь точно всё про тайм менеджмент навык и описать его не очень легко, но я постарался.

Это всё что я хотел рассказать про свой первый шаг в карьерном пути и если обобщить написанное выше в 3-4 предложениях то я наверное поделюсь следующей информацией: первый стартовый шаг на освоение базовых навыков и понимание формата работы БА занял у меня примерно 2 месяца и включал в себя:

Основной акцент в жестких навыках на документирование требований и дизайна к ним, а также изучение базовых активностей по выявлению требований, понимание структуры требований и дизайна, определение критериев готовности требований/дизайна.

Основной акцент в мягких навыках на тайм менеджменте, вопросах и конечно же командной работе.

Шаг 2 – отличный БА.