Читать онлайн книгу «Бизнес-анализ от а до я: гид для начинающих» автора Михаил Бахрах

Бизнес-анализ от а до я: гид для начинающих
Михаил Бахрах
Книга предлагает всестороннее исследование профессии бизнес-аналитика ИТ, основанное на 100% практическом опыте автора, реальных сценариях и решениях. Автор, опираясь на десятилетний опыт работы в качестве бизнес-аналитика ИТ, делится исключительными знаниями, основанными на личных успехах.Роль бизнес-аналитиков ИТ объясняется простыми словами, что делает ее доступной не только для профессионалов в этой области, но также для тех, кто вне мира ИТ и стремится попробовать себя в бизнес-анализе.В отчете LinkedIn за 2020 год навык ИТ бизнес-анализа был классифицирован как пятый по популярности и востребованности.Независимо от того, начинаете ли вы свой путь в качестве бизнес-аналитика ИТ или ищете новые идеи для профессионального роста, эта книга обещает захватывающее путешествие!

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


Кратко обо мне, бизнес-анализе и книге
Обо мне. Я решил стать бизнес-аналитиком в сфере информационных технологий (ИТ) много лет назад, после того как довольно долго пытался развиваться и вырасти в бизнес-направлениях, не связанных с ИТ – работая инженером, менеджером по продажам, руководителем компаний. В какой-то момент я понял, что а) мне хочется начать работу в компании, где я смогу получать международный опыт б) где я смогу работать без какой-либо зависимости на уровень продаж и целей/планов по продажам в) где достаточную часть рабочего времени занимала бы настоящая мозговая активность. А также в тот момент я хотел просто попробовать "а моё ли это" —новое направление в совершенно другой области/сфере работы. С некоторыми трудностями, но я устроился в международную ИТ компанию и в первые же недели работы понял, что это именно "та работа", которая мне интересна, которая у меня получается, которая заставляет мозг работать и самое главное – это та работа, от которой получаешь удовольствие. И с того момента, и до сегодняшнего дня я хожу на работу (сейчас "хожу в свою комнату в своей квартире", так как удаленный формат работы из дома это теперь вполне нормальное явление в нашем мире – кто бы мог подумать о таком до 2020 года?) не в формате "отлично сейчас поболтаю с коллегами" или "скорее бы конец рабочего дня, и я свободен". Нет. Я начинаю каждый рабочий день с мысли "отлично! Сегодня у меня есть куча интересных задач, которые мне позволят создать что-то фантастическое!" Почему работа мне не наскучила за 10 лет?  – моё понимание что тут прямо пропорциональная зависимость между показателями “личностное профессиональное развитие" и "удовольствие от работы". Если рассмотреть профессиональное развитие – с ростом опыта и экспертизы сложность новых задач, которые я готов взять в работу, так же растёт, что в свою очередь логично нагружает новыми активностями мой мозг. И наоборот – решая всё более сложные задачи я расту профессионально. Говоря про удовольствие, в нашем организме и существовании есть две основных функциональности – действовать физически и принимать информацию в мозг. И соответственно так как никаких других ключевых активностей у нас нет, то они и являются основными источниками удовольствия. Источник физические действия приносит множество видов удовольствия, которые мы все знаем – танцы, спорт, игры, и так далее. Источник, как получаемая информация в мозг приносит так же разные виды удовольствия и в том числе особенно от чего-то нового, от новой разнообразной информации. Покупаешь ты пирожное или новую машину, или просто размышляешь над новыми покупками или занимаешься новыми задачами по работе – это же процесс, который материализует это ощущение удовольствия в определенной мере, так ведь? Удовольствие от работы у меня состоит из двух основных компонентов: первой – это, как я упомянул, новые активности/задачи и второй – это постоянное понимание того, что работая, я создаю продукт (информационную систему), который кому-то нужен и важен. Мы проводим большую часть своей жизни на работе и делать это надо с удовольствием, которое так же способствует профессиональному развитию!
О бизнес-анализе в сфере информационных технологий. Что такое бизнес-анализ и работа бизнес-аналитика в ИТ? В одном коротком и простом предложении я бы описал это так: Основная цель и активность ИТ бизнес-аналитика и бизнес-анализа – это создать информационную систему/продукт, который действительно хочет бизнес. Я это говорю не с практической или теоретической точки зрения, а с точки зрения моей идеологии, которой я следую, когда работаю. Работаю = создаю продукт (да это может быть только небольшая часть системы, но это часть системы), который будет приносить пользу кому-то (компания, человек). И я специально упомянул идеологию, потому что на теоретическом и практическом уровне есть множество вариантов и направлений и объяснений, чем занимается бизнес-аналитик в ИТ и что есть бизнес-анализ. Все они верны, но мне всегда важно, чтобы я понимал, что я создаю что-то для кого-то. Какую бы работу я ни выполнял, я всегда чётко вижу связь между даже самой маленькой технической задачей, которую я делаю и финальной бизнес-целью, той системой/продуктом, которую получит бизнес клиента. В жизненном цикле создания информационной системы могут участвовать множество людей, которые выполняют разные функции и имеют разные цели, но именно бизнес-аналитик должен брать на себя (пусть даже не официально) ответственность за поставку системы, которую хочет бизнес. С каждым годом всё больше и больше клиенты понимают и соглашаются, что им нужен помощник на стороне поставщика информационной системы, кто будет представлять их интересы в создании той системы, которую клиент хочет. И лучшим кандидатом на роль такого помощника я считаю бизнес аналитика. Кстати, интересный факт, опубликованный сайтом LinkedIn в 2020 году: бизнес-анализ попал на 6 место в списке самых востребованных навыков в ИТ.
Про книгу. Я решил написать эту книгу, чтобы поделиться своим опытом с теми, кто только начинает свой путь как ИТ-бизнес-аналитик и хочет понять, как может выглядеть этот путь. Также я хочу поделиться своими знаниями с теми, кто уже работает бизнес-аналитиком и ищет дополнительные идеи для роста и развития. Вся книга написана на основании моего практического опыта с описанием реальных ситуаций и задач, а также способов их решения. За 10 лет работы я почти не пользовался теоретическими источниками или книгами – мой опыт основан преимущественно на практике и на работе с наставниками, людьми, которые знают больше и лучше в бизнес-анализе, чем я в момент моего взаимодействия с ними.
В книге я логически разделил основные главы на должностные и профессиональные уровни бизнес-аналитика: бизнес-аналитик, старший бизнес-аналитик, ведущий бизнес-аналитик, руководитель группы бизнес-аналитиков. Все эти стадии я уже прошёл, и это было потрясающее путешествие! Основываясь на своём практическом опыте и понимании, я описываю навыки, которыми, по моему мнению, должен обладать бизнес-аналитик на каждом из этих уровней. Я старался избегать подхода «книга-учебник» и сделал акцент на формат повествования, привычный для художественных книг, что делает чтение более интересным.
Сейчас, помимо своих основных обязанностей, я также являюсь владельцем каталога навыков и системы по построению карьерного пути для более чем 3000 бизнес-аналитиков в моей компании. Поэтому я уверен, что дальнейшее содержание книги окажется полезным и информативным – мой опыт гарантирует это!

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

Первая история о трудоустройстве в ИТ компанию без ИТ опыта.
Карьеру в ИТ я начал, наверное, поздновато, но определённые плюсы в этом тоже были. К своим 30 годам я успел поработать ведущим инженером по инженерным системам, менеджером по продажам и руководителем филиалов компаний в моём городе, как я упоминал ранее. Я знал, как работают инженерные процессы, как функционируют продажи, как управляется компания и бизнес в целом в любой компании, которая продает товары или услуги. Я был знаком с основными структурами компании, основными бизнес-процессами, знал, как главные показатели влияют на успешность компании и так далее. Я работал в компаниях, занимающихся дистрибуцией продуктов, и знал «от и до» цепочку получения прибыли компании с момента заключения договора с производителем товара и до момента оплаты счета конечным покупателем. Я рос по должностным позициям, готовый выполнять любую работу лишь с одной мотивацией – «заработать побольше денег». Мне было не важно, чем занимается компания, чем буду заниматься я, главное были деньги. Я прыгал между компаниями, искал новые места работы с более финансово интересными предложениями в моём городе. И в один прекрасный момент вдруг внезапно «сошлись звёзды», и я оказался а) без работы и б) демотивирован и уставший от поиска бизнес-руководящих позиций, где везде была очень прямолинейная цель и задачи: «заработай денег и много». При собеседовании тебе могли рассказывать, какая комфортная рабочая среда и какие прекрасные условия даёт работодатель, но в итоге всё сводилось к концу месяца: «нужно, чтобы твой офис принес ХХХХХ денег в следующем месяце». И вот я решил сесть за стол в свой прекрасный нерабочий день, помедитировать (не какая-то специальная медитация, а просто глубоко задуматься) и определить, какую мне выбрать мою следующую работу. Я взял карандаш и записал на самом верху листа: «Зачем я хочу выбрать себе работу в новом направлении?». А действительно – зачем мне нужно выбрать работу? Ведь по идее разных вакансий много. Я вспоминаю свой опыт работы последних нескольких лет и стараюсь серьёзно не задумываться, а написать первое, что приходит в голову (по факту быстрые импульсы-мысли из подсознания): «чтобы не работать ради денег», «чтобы не просили выполнять планы по продажам», «чтобы не руководить», «чтобы я мог применить свои инженерные навыки и ум», «чтобы получать удовольствие от работы». Думаю, я набросал этот список за минуту-две, и он мне понравился.
После этого я просмотрел список наиболее востребованных вакансий на сайтах о работе. Моё внимание привлекли вакансии, связанные с растущим спросом на ИТ-специалистов. Я видел множество разных ИТ-позиций, но наиболее понятной для меня была позиция бизнес-аналитика. Я отправил своё резюме в несколько ИТ-компаний, и мне, естественно, везде пришли отказы, так как у меня не было ИТ-опыта. Время шло, и в один прекрасный день я встречаюсь со своим братом и делюсь своими мыслями о ИТ-мире, в который, видимо, мне были закрыты двери. И вдруг он сообщает, что его друг по школе, сейчас по чистой случайности (вот это совпадение!), работает бизнес-аналитиком в ИТ-компании и что он с ним поговорит. Признаюсь честно, я всё равно настроен не очень позитивно, так как мне везде отказывали в ИТ-компаниях, даже если я согласен на любую позицию стажера. Через несколько дней брат звонит и сообщает, что договорился со своим школьным товарищем, что тот посмотрит моё резюме. И подбадривает меня: «У нас всё получится – можно устроиться в любую компанию, если настроиться на успех типа ‘я хочу, я смогу!’»

Среди хороших психологических мотиваторов, которые описывают множество авторов в мотивирующей литературе, у меня всегда в голове хранится только один. Хотя, возможно, он и не из книг-мотиваторов (не очень люблю такие книги, так как они, на мой взгляд, оказывают лишь кратковременный эффект). Смысл этого мотиватора следующий: когда у тебя возникает мысль что-то сделать или предпринять для достижения цели, и ты начинаешь сомневаться, стоит ли вообще начинать, всегда представляй два варианта развития событий:
Первый вариант – ты что-то сделаешь и а) у тебя не получится, б) у тебя получится.
Второй вариант – ты ничего не сделаешь, и этот вариант, по сути, равен варианту «б» из первого. Из чего следует простое логическое заключение, что второй вариант бессмысленно выбирать, если он уже включен в первый. Поэтому я всегда двигаюсь по первому варианту – попробую, посмотрю результат, сделаю выводы и попробую дальше.
Я отправил своё резюме и стал ждать ответа. Через некоторое время мы созвонились, и друг брата сообщил, что есть два основных замечания по резюме. Первое – в моем резюме отсутствует упоминание факторов, которые могли бы заинтересовать ИТ-компанию. Должен быть якорь, что-то, что зацепит человека, просматривающего резюме, с точки зрения навыков. Хотя бы небольшой кусочек информации, который станет поводом для разговора с кандидатом. Это может быть личный опыт вроде "в свободное время пишу программы" или знание бизнес-процессов, например, "я детально знаю, какие бизнес-процессы существуют в компаниях". Второе замечание касалось того, что резюме – это "лицо" кандидата, первый контакт с компанией и первое впечатление о тебе. Поэтому моя первая версия резюме не выглядела как привлекательное "лицо".
Я провёл неделю, обновляя резюме и пересматривая пункты, которые могли бы продемонстрировать мою полезность для ИТ-компании. После повторной отправки резюме, он сказал, что теперь "резюме можно показывать коллегам в компании" и что он поговорит со своим руководителем о том, чтобы организовать мне собеседование. Через неделю мне назначили собеседование с руководителем отдела ИТ-бизнес-аналитиков в моем городе. Вот это новость!
Теперь мне нужно подготовиться к собеседованию и разобраться: что за компания, куда я устраиваюсь, чем она занимается, чем буду заниматься я, если меня возьмут на роль бизнес-аналитика, и как я смогу применить свои текущие навыки и опыт. Подготовка к собеседованию включает изучение компании и специфики моей потенциальной работы. Даже если у меня нет практического опыта в этой профессии, я должен понимать, что делает ИТ-бизнес-аналитик, как и зачем. На собеседовании обычно проверяют практический опыт кандидата, а если его нет или он не соответствует требуемому уровню, то проверяют знания и понимание навыков через вопросы по воображаемым сценариям. Понимание границ ответственности и обязанностей на занимаемой должности поможет мне правильно ответить на задачи.
Неделя прошла в подготовке и ожидании дня собеседования. Часть этой подготовки занимала постоянная и самоутверждающая интенсивная бомбардировка сознания мыслями, которые создавали по крайней мере личную убеждённость в том, что моё трудоустройство обречено на успех. Обречено, потому что я – именно тот, кто нужен этой компании; я знаю бизнес-процессы, которые помогут в создании ИТ-продуктов; я готов пройти собеседование таким образом, чтобы показать себя в наилучшем свете; я готов ответить на любые вопросы и решить практические задачи, которые могут мне задать. Психологически я настроен на то, что всё пройдет успешно, ведь для победы у меня должно быть внутреннее состояние, будто я уже победил, или будто я уже оформляюсь на новую работу, как будто собеседование уже позади. В моём мозгу не должно быть ни одной мысли, связанной с собеседованием в стиле «попробую, может повезет» или «начну рассказывать, а там как пойдет», или «если не пройду, то поищу другие вакансии», или «это не конец жизни, если не пройду это собеседование». Да, мы понимаем, что при прохождении собеседования основной акцент делается на оценке профессиональных навыков, но в дополнение к этому важную роль играет и уверенность в себе, которая должна исходить от кандидата – в его разговоре, тоне голоса, языке тела, степени уверенности. Именно этот фактор «я тот, кто нужен» часто добавлял дополнительный плюс кандидату на собеседованиях, которые я проводил. Этот плюс влиял на создание общей картины результатов собеседования.
Наконец наступил март 2013 года и день собеседования. Погода была отличная – на улице еще прохладно, но в солнечный день уже чувствовалось наступление весны, когда солнце грело, и в воздухе ощущалась теплая свежесть, создавая лёгкость настроения. Но только не для меня в этот день. Уже с самого утра у меня был включен «режим опасности». Это очень полезный, но в то же время нервно-истощающий режим для мозга, который активируется у любого существа на планете, когда оно чувствует опасность, и все рецепторы восприятия обостряются, а нервные окончания становятся очень чувствительными. Это состояние не связано со страхом неудачи. Ведь жизнь большинства людей не связана с реальной угрозой для жизни в повседневной жизни, но у людей это психологическое состояние возникает по другим причинам, которые влияют на нормальный ход жизни и ценности. В моем случае, если я знаю, что трудоустройство на работу напрямую влияет на благополучие моей семьи, то это, естественно, приводит к активации состояния опасности. Мысли только о предстоящем собеседовании крутились в голове, ладони потели, во всем теле ощущалось внутреннее напряжение и небольшая нервозность. Я был полностью сконцентрирован на предстоящем собеседовании, которое должно было начаться через 2–3 часа.
Наконец наступило время собеседования. Я зашёл в новый бизнес-центр нашего города, поднялся на 12-й этаж и был приглашён в комнату для собеседований. Там меня встретил руководитель отдела ИТ-бизнес-аналитиков. Само собеседование с первой минуты мне понравилось, поскольку оно скорее напоминало диалог двух заинтересованных бизнес-сторон, а не типичное собеседование в формате «а ты это знаешь?» или «а вот это ты делал?». Мне было приятно, что мы обсуждали мои знания, которыми я делился, а представитель компании оценивал, насколько и где их можно применить в деятельности, которую выполняют бизнес-аналитики в этой компании. Он не искал способа задать мне вопрос, на который я не смог бы ответить, хотя это было бы довольно просто, учитывая, что у меня нет практического опыта в БА. Например, я не знаю ничего о цикле разработки программного обеспечения. Зато я хорошо знаком с бизнес-циклом и процессами ведения клиента от первого контакта до завершения сделки. И моя ключевая польза для компании связана с тем, что есть направление разработки компонентов ИТ-системы, которые будут отвечать за управление жизненным циклом отношений с клиентом.
В конце собеседования проверили мои знания английского языка, который, естественно, необходим для бизнес-аналитика. Я не носитель английского языка, и мои знания были лишь теоретическими, так как всю жизнь я работал в местных компаниях моего города, не связанных с международными проектами или клиентами. Мой уровень английского слаб в плане коммуникации, но базово достаточен для начала работы бизнес-аналитиком, который не будет общаться с клиентами.
Как итог собеседования, руководитель отдела сразу сообщил мне, что они готовы сделать мне оффер (предложение о работе) и взять на работу на определённых условиях контракта, после чего мы закончили собеседование. Я вышел из офиса компании в каком-то парящем настроении. И это чувство было вызвано не столько результатами собеседования, сколько фактом завершения задачи. Внутреннее напряжение исчезло, как и мысли о подготовке и самом собеседовании.
Когда я вернулся домой и сел на кровать с хорошим настроением, но безработным, я начал размышлять обо всех «за» и «против» оффера, который мне сделали в новой ИТ-компании, и его перспективах. Перед принятием решения нужно было проанализировать не столько «за и против», сколько «за и риски», так как «за и против» следует оценивать ещё на этапе первого контакта с потенциальным работодателем.
На самом деле, в колонке «за» у меня мало что можно записать. Главное «за» – это моё огромное желание кардинально сменить сферу деятельности. Дополнительные «за» включают в себя то, что мне в общем понравилась специфика предложенной должности, а также сам формат компании – большая, международная, и, как мне показалось, с довольно стабильными перспективами профессионального и карьерного роста. На этом всё.
Более серьёзные размышления у меня вызывали риски. Для любого человека, особенно для семейного, вопрос уровня зарплаты является приоритетным, особенно после определённого времени без работы. Предложенная зарплата оказалась на 40% меньше, чем я зарабатывал последние 2-3 года. С одной стороны, новая область очень интересует, но есть и обратная сторона медали – вопрос самому себе: «А пойдёт ли у меня это направление и насколько успешно?» Ведь я никогда не работал в этом домене и даже приблизительно не могу оценить свой потенциал. И будет ли мне нравиться этот вид деятельности?
В итоге, как обычно, чем больше загружаешь голову противоречивыми мыслями или взвешиванием возможных решений, тем больше сомневаешься в правильности принятия какого-либо решения. И я принимаю, как мне кажется, единственно правильное решение – лечь спать и завтра утром, на свежую и пустую от мыслей голову, быстро спросить самого себя и мгновенно интуитивно ответить себе, что я решил.
Я просыпаюсь утром, смотрю на потолок и думаю о своей новой возможной работе и решаю, что я точно хочу попробовать эту новую работу ИТ-бизнес-аналитиком. Я захожу в почту на моём ноутбуке и отсылаю письмо компании, что принимаю предложение и готов выйти на работу. Чувствую себя очень легко и спокойно – обычно так бывает, когда принимается осознанное решение, которое полностью совпадает с подсознательным (интуицией). И даже волнующие и нервные мысли о новой работе, прилетающие в течение дня, всё равно создают атмосферу интригующего ожидания чего-то абсолютно нового!
На следующей неделе я выхожу на свою абсолютно новую работу. Это очень волнительно, так как я абсолютно ничего не знаю о моем новом рабочем месте и обязанностях в деталях. Вот и мой первый день в первой ИТ-компании. Я одет, как обычно на первый день в любой компании – рубашка, брюки и туфли (хорошо, что не одел галстук). Я захожу в HR отдел, где получаю информацию о том, где будет мое рабочее место и на каком этаже оно находится. Руководитель команды аналитиков также находится на моем этаже, поэтому я сначала подхожу к нему поздороваться, и он показывает, где я буду сидеть. Рабочее пространство мне нравится – это так называемое «открытое пространство» (open space). Весь этаж без стен, кроме комнат для совещаний. Несколько рядов столов, за которыми работают коллеги. Руководитель кратко представляет меня коллективу – на моем этаже работает большинство бизнес-аналитиков. Меня удивляет, что все одеты как хотят – кто в джинсах, кто в майке, а кто и в шортах. В следующие дни я быстро привыкаю к этому свободному дресс-коду, способствующему комфортной работе, которая в основном связана с персональным компьютером.
В первые дни мне нравится, что у меня сразу появляются реальные задачи, и я погружаюсь в удаленный/распределенный формат работы. Это происходит потому, что компонент ИТ-системы «Системы по поддержке бизнеса», в котором я участвую, не имеет проектной команды в офисе моего города. Поэтому мне определяют проектного ведущего БА и одновременно моего наставника (ментора) из другого города. Следующие 2 или 3 года я работаю с моим ментором полностью удаленно – не разу не увидев его вживую. С первого знакомства я интуитивно чувствую, что мне попался очень хороший ментор в прямом смысле этого слова – тот человек, который может помочь и существенно ускорить усвоение необходимых БА навыков и специфики работы на проекте. Никакой теории – он сначала показывает, чем занимается сам: анализирует бизнес-требования, создает функциональные требования, общается с коллегами по проекту, общается с клиентом для уточнения деталей о требованиях к системе. Он кратко описывает свои обязанности, но, естественно, эти активности я выполнять не буду. Сначала он дает мне очень простые задачи, но именно такие, которые должны поставить меня на "рабочие рельсы". На этих простых задачах я следующие несколько месяцев оттачиваю одни из ключевых навыков любого бизнес-аналитика, такие как анализ и документирование функциональных требований для системы, последовательность, структурированность и логичность написания, простота и понятность изложения, эффективное переиспользование форматов/шаблонов и частей уже существующих требований. Я четко понимаю, что это обязательная база, и рад, что мой ментор не дает мне более сложных и разнообразных задач. В этом просто нет смысла, так как любая профессия всегда имеет градации уровня владения профессиональными навыками. Главное в любой профессии – это поэтапно повышать свою квалификацию и обязанности.
Теперь давайте рассмотрим тему трудоустройства бизнес-аналитика в ИТ-компанию с другой стороны – перейдем от моего лирического жизнеописания к более практическому повествованию. Добавлю свои рекомендации и уроки, которые я извлек на основе текущей реальности.
Итак, существует два основных и логичных сценария трудоустройства: 1) без опыта в ИТ-сфере и 2) с опытом работы в ИТ как бизнес-аналитик. Я не буду здесь рассматривать дополнительный сценарий, когда человек с опытом не-БА работы в ИТ хочет стать БА, так как для таких людей самый простой путь – это сначала устроиться в нужную компанию на своей текущей должности, а затем уже внутри компании планировать переход на должность БА.
Оба варианта очень похожи с точки зрения процесса и подготовки. Что бы я выделил:
–Построение мыслей как база для создания настроения и принятия решений.
–Планирование начала карьерного пути, включая план трудоустройства.
–Подготовка резюме и прохождение собеседований.

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

2. Знание языка (этот фактор не актуален для носителей английского языка или для тех, кто трудоустраивается в не международную компанию) – без знания английского языка сейчас, я думаю, трудоустроиться не получится. Да, уровень владения языком может быть совершенно разный, но в какой-то базовой форме он точно должен быть. Я бы разбил для БА уровень владения на три уровня. Нет, не официальные уровни, принятые в мире как A1, A2, B1 и так далее, а именно уровни, которые будут влиять на ваше трудоустройство, уровень позиции, на которую вас будут готовы взять, и, естественно, вашу привлекательность для работодателя. В работе БА в контексте использования языка можно выделить три вида основных типов активностей:
– Подготовка и управление артефактами (документированные результаты задач, необходимые для выполнения проекта/продукта) и процессами – умение писать на необходимом языке любую документацию.
– Коммуникация с клиентом – умение вести свободные переговоры с представителями клиентов (под «клиентами» я подразумеваю тех, кто не является частью вашей проектной/продуктовой команды, а являются частью той команды, для которой вы делаете проект/продукт).
– Коммуникация с командой – умение общаться с командой в процессе создания продукта/проекта.
В зависимости от одного из этих уровней работодатель может определить, насколько вы подходите для открытой позиции. В моём практическом примере, когда я трудоустраивался в свою первую ИТ компанию, моего владения английским языком хватало только на первый уровень для написания документации. Но этого было вполне достаточно, так как я трудоустраивался в продуктовую компанию, где серьёзный акцент был на разработке собственных продуктов и у многих БА коммуникация с клиентом вообще не входила в обязанности. Я думаю, в данный момент, у многих изучение английского языка начинается возможно даже с первого класса школы, и довести уровень до одного из трёх уровней не должно быть сложной задачей. Также сейчас есть тысячи бесплатных курсов, программ, книг для изучения. И чтобы повысить свою привлекательность для работодателя, можно запланировать, мне кажется, в течение 2-3 месяцев достичь 1 или даже 2 уровня, а за 6-8 месяцев – 3 уровня, то есть свободного базового владения разговорным английским языком для коммуникаций. Этот критерий хорош тем, что нет никаких препятствий для его развития – всё полностью зависит от вас.

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

4. Опыт в бизнес-анализе – это самый естественный и выгодный критерий: наличие опыта в профессии БА. Однако понятие 'опыт' весьма растяжимо и насколько ваш опыт соответствует ожиданиям работодателя, определяют несколько факторов. Первый критерий – это, разумеется, продолжительность вашего опыта. Если у вас более двух лет опыта, это уже можно считать позитивным. Однако этот критерий всегда рассматривается в связке с двумя следующими. Второй критерий – это масштаб вашей работы: какими видами активностей вы занимались, на каком уровне и масштабе проектов вы работали, сколько проектов вы завершили от начала до конца. Третий – это масштаб ИТ-компании, где вы получали опыт БА. Нужно понимать, что если трудоустройство происходит в более зрелую ИТ-компанию, то и её стандарты к найму БА будут выше. Например, человек работал в ИТ-компании из 15 человек над одним проектом по разработке одной из 100 функций системы в течение двух лет. При трудоустройстве в компанию на 10000+ человек его опыт может рассматриваться как недостаточный. Однако, учитывая огромное количество материалов, статей и книг в интернете о БА, этот критерий можно самостоятельно развивать до нужного уровня в любой компании за 3–6 месяцев, получая необходимый практический и теоретический опыт. Для тех, у кого нет практического опыта в БА, я бы также рекомендовал прокачивать этот критерий хотя бы с теоретической точки зрения – это будет полезным дополнением к вашим остальным критериям, если вы пройдете курс или изучите материалы о бизнес-анализе в ИТ.
Исходя из оценки этих критериев, можно предложить правильные временные рамки для начала деятельности по трудоустройству в компанию, которую вы выбрали. Это важно: планирование должно быть основано на ваших личных критериях:
А) Трудоустроиться за 1-2 месяца: это возможно, если у вас уже есть хороший опыт в БА или вы обладаете значительным опытом в одном из бизнес/операционных доменов, а также отличным знанием английского языка и, возможно, теоретическими знаниями о бизнес-анализе и ИТ.
Б) За 3-6 месяцев: если ваш опыт в БА недостаточно зрел для трудоустройства в новую, более развитую компанию, этого времени хватит для изучения лучших практик БА. Также это время можно использовать для улучшения знания английского и теоретических знаний в БА, если у вас уже есть солидный доменный опыт.
С) За 12 месяцев: этот срок предназначен для людей без опыта в БА, которые планируют трудоустройство в крупную компанию на высокую должность. Начав работать в меньшей компании с менее строгими требованиями, за год или два можно набраться необходимого практического опыта. Также это время позволяет людям с БА-опытом проанализировать и улучшить свои знания и навыки, расширяя зоны ответственности или меняя проекты в текущей компании.
А вот какие у вас могут быть пробелы, на каком уровне и как улучшить или развить свои навыки, будет описано в следующих главах. Одна из целей этой книги – помочь человеку без опыта в БА или с таким опытом проанализировать свой текущий уровень и построить план личностного развития и роста в БА в краткосрочной, среднесрочной и долгосрочной перспективе. Важный пункт для тех, кто только планирует войти в БА домен или, например, работает как БА в компании, где интуитивно понимает, что не получает нужной экспертизы для перехода в другую. Этот пункт может также изменить временные рамки на подготовку к трудоустройству. Говоря о курсах подготовки БА, на рынке существует множество курсов по переквалификации из другой специальности в БА или просто по повышению квалификации в БА. Курсы, естественно, платные, и цель любого курса в мире (не только БА) – заработать деньги для их организаторов. Поэтому перед регистрацией на курс рекомендуется внимательно изучить его программу и выбирать те, где практические занятия занимают значительную часть программы. Потому что теорию можно бесплатно найти в интернете, а практические задания, где вы будете выполнять работу БА и наблюдать, как квалифицированные тренеры выполняют такие задачи, предоставляют бесценный опыт. Также стоит обратить особое внимание на курсы, организуемые непосредственно компаниями-работодателями, так как они могут предложить более ценный и практический опыт, который будет полезен в долгосрочной перспективе. Например, громадная компания, где я сейчас работаю, часто организует не просто БА курсы, а так называемую БА лабораторию, лучшие выпускники которой получают предложения о трудоустройстве. Выбор работодателя, будь то маленькая компания или крупная с высокими требованиями, существенно влияет на успешность трудоустройства с учетом описанных критериев.

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

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

Второй тип компаний – компания-поставщик ИТ-продуктов. Это компания, которая разрабатывает свой ИТ-продукт, который поставляется другим бизнес-клиентам. Например, моя первая ИТ-компания была именно такой компанией-поставщиком ИТ-продукта в телекоммуникационном домене. Есть интернет-провайдеры, которым нужны ИТ-продукты/программы, помогающие им управлять и увеличивать эффективность и продуктивность своих бизнес-процессов. Например, каталог хранения продуктов необходим абсолютно любому телеком-оператору, который предлагает услуги интернета, мобильной связи, телевидения. Такой компании не нужны услуги ИТ-сервисной компании. Им нужен конкретный продукт, который будет им поставлен и модернизирован под их нужды и требования. Какие позитивные критерии я бы озвучил об этих компаниях?
В первую очередь это возможности получения глубокого доменного и продуктового опыта. Это прямо противоположное преимущество по сравнению с сервисными ИТ-компаниями. Опять же, всё зависит от желания и планов конкретного человека, как я уже говорил – поэтому я и описываю это. Представьте, вы приходите в продуктовую компанию, которая последние 10-15-20 лет разрабатывает один продукт (или линейку продуктов) в конкретном бизнес-домене. Вы включаетесь в разработку продукта и предоставление этого продукта клиентам. У вас есть отличный шанс получить глубокие доменные знания, а также специфические подходы к созданию и поставке решений для доменных клиентов. С течением времени вы станете экспертом в данной области/домене.
Вторая перспектива – это подготовка решений для клиентов на базе зрелых продуктов, которые ваша компания уже имеет. Вы не создаёте что-то с нуля в плане продукта; вы точно знаете и, возможно, уже являетесь экспертом в продуктах, которые нужны клиенту. Вы уверенно проводите сбор требований, чтобы поставить продукт в нужной конфигурации. Именно вы – эксперт, который приходит к клиенту и рассказывает, что и как будет создано и будет работать на основании высоких стандартов. Это приятное ощущение – проверено на собственном опыте.
Один нюанс: переменчивая динамика БА-экспертизы в самом процессе разработки и поставки ИТ-решений/продуктов. В компании, которая уже имеет продукт на продажу и успешно поставляет этот продукт, например, последние 10 лет клиентам, может не быть, например, детально проработанных требований и описания обязанностей для БА. Может отсутствовать обучающая база, которая, например, может быть в компании-поставщике сервисных услуг (так как их главный козырь – это люди, а не продукты). Здесь акцент на глубокое знание именно продукта, который нужно поставить клиенту, а не на улучшение знаний и экспертизы в конкретной компетенции/профессиональной области сотрудников.
И последний тип компаний – это не ИТ-компании, то есть бизнес-компании. Такие компании не предоставляют ИТ-услуг или продуктов. Например, компании-поставщики товаров народного потребления, автомобильные компании, банки, страховые компании и так далее. Но в таких компаниях обязательно есть ИТ-департамент, и он может быть достаточно большим, чтобы иметь БА (или даже отдел БА).
Из перспектив я бы, наверное, отметил то же самое, что и для второго типа компаний – поставщиков ИТ-продуктов: доменные и продуктовые возможности. Вы, как часть такой компании, получаете доменные, продуктовые и процессные знания и навыки на разных уровнях компании, и не только в ИТ-части.
Из нюансов я бы выделил тот же пункт с переменчивой динамикой экспертизы в области БА – иногда на весь ИТ-департамент может приходиться всего 3-5 БА, и вы один из них, соответственно, не идет речи о каком-либо развитии БА-экспертизы. Ещё я бы, наверное, добавил второй нюанс, что есть вероятность, что ИТ-департамент будет выполнять то, что «спускают сверху» вниз руководители других бизнес-департаментов, и соответственно гибкость в создании или изменении чего-либо будет минимальна («бюджет утвердили – задачу сказали – делай и не задавай вопросов»).
Вот собственно и все о типах компаний – если есть ещё какие-то виды, то в большинстве случаев это гибриды из этих трех.
И уточню еще раз мои формулировки и пояснения про "нюансы" – это только нюансы и ни в коем случае не негативные пункты. Также мы понимаем, что абсолютно каждый человек индивидуален в своих рабочих/профессиональных стремлениях, и то, что для одного может быть нюансом, для другого может быть перспективой.
Выбирайте формат своей компании на основании ваших целей/стремлений – хотите ли стать экспертом в области БА или в определенной продуктовой/доменной области. Любите ли вы частую смену вида деятельности или вам это без разницы.
Мы обсудили возможных работодателей, проанализировали свои сильные и слабые стороны, и определили приблизительные временные рамки, которые мы готовы потратить на достижение своей цели. Остается решить последний, но не менее важный вопрос, без которого невозможно трудоустройство: составление резюме, подготовка и прохождение собеседования.

Подготовка резюме
Этот пункт я описываю исключительно с практической точки зрения, с учетом моего опыта как менеджера по проведению БА собеседования для приема на работу. Я просмотрел резюме и собеседовал множество кандидатов за последние 5 лет и, на мой взгляд, по факту есть несколько пунктов, которые нужно учесть. Некоторые из них, возможно, могут показаться очевидными, но я видел достаточно резюме и собеседований, где эти пункты были упущены кандидатами.
Хорошо составленное резюме понадобится для самого первого шага при поиске работы – это тот документ/артефакт, который отправляется потенциальному работодателю. Резюме – это первое впечатление работодателя о вас. И у работодателя может быть несколько отделов, которые будут просматривать это резюме. Например, естественно, сначала будут смотреть сотрудники HR-отдела, и для них важно из резюме увидеть основные факты, которые укажут на то, что ваша кандидатура частично или полностью соответствует тем требованиям, которые у них указаны для открытой вакансии. Только после нахождения таких фактов обычно HR-сотрудники передают CV/резюме дальше. Небольшой пример моего опыта отправки резюме без фактов о ИТ-опыте – не один HR-сотрудник ИТ-компании не заинтересовался моим резюме, когда я в самом начале разослал моё обычное не ИТ-резюме в несколько ИТ-компаний города.
Думаю, в интернете есть тысячи статей про составление резюме, поэтому здесь я только кратко коснусь некоторых полезных аспектов/рекомендаций и приведу примеры трансформации моих реальных резюме. Я не говорю, что они идеальны, но это форматы, которые я использовал.
Про аспекты – я хочу выделить следующие:
1. Соответствие информации в резюме требованиям открытой вакансии. Даже если у вас имеется значительный и выдающийся опыт, не связанный с указанным в вакансии, не стоит делать на нем акцент в резюме. Важно тщательно изучить описание вакансии и требования к опыту. Затем подумайте, как описать свой опыт так, чтобы он максимально соответствовал требованиям вакансии. Если вы ищете работу в ИТ без соответствующего опыта: например, если у вас нет опыта работы в ИТ-компании, но вы работали в банке с кредитными продуктами, вероятно, вы использовали ИТ-системы для управления кредитными продуктами. В таком случае укажите свой опыт работы с ИТ-системами в банковской сфере и опишите свои знания. При смене работы: например, если вы рассматриваете позицию бизнес-аналитика с обязанностями владельца продукта (product owner), и у вас нет опыта работы владельцем продукта, но некоторые ваши активности схожи, вы можете изучить обязанности владельца продукта и сделать акцент на них в своем резюме.

2. Логичное структурирование информации по значимости – в начале следует изложить суть: ваши ключевые навыки и опыт. Это первое, что увидит читатель, так как любое резюме читается сверху вниз. Ваши ключевые достижения и знания следует описать кратко, но ясно, и только после этого переходить к описанию всех деталей. Например, если у вас есть опыт работы бизнес-аналитиком (БА), сначала укажите список основных обязанностей и навыков, а затем подробно опишите последние проекты, в которых вы участвовали.

3. Компактность резюме – избегайте описания всех своих проектов или лет трудовой деятельности в мельчайших деталях на 15-20 страницах. Как правило, 3-4 страниц достаточно для описания вашего опыта, так как любые дополнительные детали могут быть уточнены на собеседовании, если ваше резюме вызовет интерес.

4. Соответствие информации в резюме вашему реальному опыту – старайтесь не указывать навыки и знания, которые вы не можете применить на практике, особенно если вас могут попросить продемонстрировать их во время собеседования. Простой пример из собеседования, которое я проводил: пришел кандидат на позицию старшего БА. Перед собеседованием я, как обычно, просмотрел его резюме и в нем было очень широко и подробно указано владение основными БА навыками, которые мы в компании как раз ожидаем от БА. Один из пунктов в резюме описывал навык создания диаграмм определенного формата с перечислением нескольких основных типов диаграмм. Где-то во второй половине собеседования я решил уточнить у кандидата, какие диаграммы он использовал на последнем проекте. Он ответил, что не использовал диаграммы и вообще никогда ими не пользовался. На мой вопрос про этот пункт в резюме он просто сказал, что проходил диаграммы на последних курсах в университете…

А теперь давайте я покажу пример моего резюме и его трансформацию. Поскольку полное резюме занимает слишком много страниц, я продемонстрирую только его часть. Это поможет отразить основной формат презентации и содержание:



Примечание автора: пример резюме на английском языке. Перевод не требуется – на изображении перечислены места работы и смысловое описание указано ниже.

Это было моё первое резюме, когда я устраивался в ИТ компанию впервые, о которой я упоминал несколько страниц назад. В этом резюме я допустил ошибки по всем ранее обсужденным аспектам. Однако был позитивный момент: знакомый, который помогал мне с трудоустройством, посоветовал мне адаптировать резюме в соответствии с требованиями к должности. Хотя у меня не было опыта в ИТ-секторе, я выделил те аспекты, которые были важны для позиции, на которую я претендовал. Ниже приведён пример, где я добавил раздел 'ИТ навыки' (IT Skills) и указал не только ИТ-навыки, но и другие качества, применимые к должности бизнес-аналитика, такие как аналитические навыки, опыт взаимодействия с клиентами и знание CRM/ERP систем:


Примечание автора: пример резюме на английском языке. Перевод не требуется – на изображении перечислены места работы и смысловое описание указано выше.

Моё второе резюме я подготовил после нескольких лет работы в своей первой ИТ-компании. К этому моменту я уже имел актуальный опыт работы бизнес-аналитиком, который я стремился грамотно представить, и также уделил внимание дизайну резюме. Однако, я не учёл важность компактности: документ получился объёмным – на 11 страницах. Включив в него весь свой опыт и все места работы, я понял, что такой подход, возможно, не был лучшим решением. Вот как оно выглядело:



Примечание автора: пример резюме на английском языке. Перевод не требуется – на изображении перечислены места работы и смысловое описание указано выше.

Моё третье и финальное резюме отражает мою редкость смены работы в ИТ-секторе – я менял место работы всего один раз, поэтому и версии резюме обновлялись нечасто. В этой последней версии я решил придерживаться полного минимализма в дизайне, исходя из понимания, что основное в резюме – это текст, который будет читаться, а всё остальное вторично. В резюме я сфокусировался на всех ключевых аспектах: 1) консолидированная информация о моём опыте, 2) обобщённая информация о ключевых навыках, обязанностях и ролях, 3) краткий обзор карьерного пути. Всё это я уместил на четырёх страницах.


Примечание автора: пример резюме на английском языке. Перевод не требуется – на изображении перечислены места работы и смысловое описание указано выше.


Прохождение собеседования
После отправки резюме наступает время подготовки к собеседованию. Вот несколько стандартных рекомендаций, которые я могу предложить:
Первая – тщательно изучите описание вакансии и обязанностей. Это поможет вам быть готовым задать уточняющие вопросы, адаптировать свой опыт к ожиданиям работодателя и заранее подумать о том, как себя вести и что отвечать на вопросы о возможных пробелах в вашем опыте или навыках. Вторая – изучите информацию о компании: её деятельность, продукты и т.д. При прохождении собеседования я обычно даю два основных совета: «будь собой» и «проясняй и задавай вопросы». «Будь собой» означает использование ваших естественных коммуникативных навыков и подлинное представление вашего опыта и знаний. Прояснять и задавать вопросы – это ключевой элемент собеседования, который может значительно повлиять на его результаты. Например, если работодатель задаёт вам практические задачи и что-то остаётся непонятным, лучше уточнить. Также, если вам объясняют специфику работы в компании, и что-то вызывает сомнения, не стесняйтесь спрашивать – это может стать решающим фактором в вашем решении о работе на данном месте.
Важно также всегда воспринимать собеседование как равноправный диалог между двумя сторонами. Помните, что это не только компания выбирает сотрудника, но и вы выбираете место, где хотели бы работать. Мне очень нравится такой психологический настрой. В моей голове он выглядит как внутренняя мысль: «Всем привет! Давайте обсудим, в чем мы можем сотрудничать!». Конечно, это не следует говорить сразу же, как только вы приходите на собеседование, но держать эту мысль в уме полезно. Такой настрой поможет вам оценить, насколько компания открыта и подходит именно вам. Надеюсь, что мои практические советы окажутся полезными!

Советы при смене места работы:
Если вы работаете как бизнес-аналитик и задумываетесь о смене места работы или уже получаете заманчивые предложения от других компаний, рекомендую обратить внимание на следующие нюансы. Эти критерии, которые я собрал на основе своего опыта и опыта моих коллег, помогут вам сделать осознанный выбор перед принятием предложения о работе от новой компании:
1. Большие деньги – конечно, без этого никуда. Прежде чем укоренить в себе мысль «Охххх, от такой зарплаты я не могу отказаться!», учтите следующее:
1. Величина зарплаты:
Если предложение на 30-40% выше текущей зарплаты, возможно:
а) Ваша текущая компания может предложить аналогичное увеличение, пусть и не сразу, но после некоторых договорённостей.
б) Оцените, насколько предложенные условия лучше тех, что есть у вас сейчас.
Если увеличение составляет 50% и более, я бы рекомендовал очень внимательно рассмотреть следующие аспекты. Особенно если предложение поступает из той же локации – это может вызвать подозрения, почему компания предлагает значительно больше без явных на то причин.

2. Предложения из других городов или стран:
Обязательно изучите уровень жизни в целевом городе. Сайты с данными о среднем уровне расходов помогут вам сравнить стоимость жизни.
Внимательно изучите налоговую систему. Во многих странах зарплата указывается до вычета налогов (гросс). Разделите предложенную сумму на 12 месяцев, вычтите налоги и оцените, будет ли достаточно оставшейся суммы для вас и вашей семьи. Обратите внимание на такие нюансы, как прогрессивное налогообложение, которое может значительно увеличить налоговую ставку в зависимости от уровня вашего дохода.

3. Условия предложения:
Не стесняйтесь уточнять детали. Например, если вам предлагают зарплату ХХХ ХХХ р и бонус ХХ ХХХ руб за трудоустройство, уточните, входит ли бонус в общую сумму и подлежит ли налогообложению. Также узнайте, существуют ли какие-либо обязательства, например, обязательство не увольняться в течение года, иначе бонус придется возвращать. Эти моменты не являются негативными; они просто требуют внимания и должны быть учтены при принятии решения.
Условия работы (а точно ли они комфортны?) – Как будет выглядеть ваш рабочий процесс? Уточните детали: а) Рабочий день. Возможно, вы последние несколько лет работали из дома в свободном режиме. В данной компании могут требовать работу «только из офиса», или, например, «из дома, но с установкой специального ПО для контроля времени», или «рабочий день у нас строго с 9 до 18 часов, и возможны просьбы задерживаться до 20 часов по просьбе проекта». Подумайте, готовы ли вы к этому? Иногда размер зарплаты, рабочий режим и список обязанностей действительно могут быть взаимосвязаны. Работаете ли вы 10-12 часов в день и выполняете обязанности «БА, который заменяет тестировщика, менеджера, скрам-мастера и кого угодно ещё»? б) Какие обязанности от вас ожидают? Если вам скажут, что «БА в нашей компании также выполняет полностью обязанности тестировщика», вам это окей? в) Тип компании – ранее я уже описал основные варианты компаний с их нюансами. Это тот тип, где вы видите себя? г) Проекты/продукты, над которыми вы будете работать, и какая у них временная шкала? Для БА важно понимать, что он будет создавать и как долго. Уточните, какой продукт или проект вы будете поддерживать: это создание нового продукта или поддержка существующего, каков размер команды, сколько уже длится проект или, если только начался, на какой примерно период рассчитан. Получив эту информацию, вы можете понять, насколько интересно вам в целом предложение или есть ли тревожные сигналы. Например, если вам долго рассказывают о громадном масштабном проекте по созданию нового продукта и на ваш вопрос о составе команды сообщают, что планируется команда всего из 5-7 человек, то масштабный проект с таким количеством людей вряд ли возможен.
Контекст и стабильность компании (не окажется ли, что завтра меня попросят уйти?) – Я сталкивался с ситуацией, когда коллега планировал уйти в другую компанию, но после нашего совместного анализа этой компании, он передумал именно из-за этого критерия. А) Оцените размер компании. Например, если вся компания насчитывает 100-200 человек или меньше, то стоит хорошо подумать. Б) Проверьте отзывы на сайтах о работодателях. Не стесняйтесь задавать такие вопросы, как «Сколько у вас всего БА в компании?» или «Сколько у вас сейчас активных проектов и какова средняя численность команд на проектах?». Если, например, в компании сейчас всего 5-10 БА, а вы только начинаете свой путь в качестве БА, то вам следует понимать, что вероятность получить достаточно опыта и возможностей для роста в такой компании может быть не велика (хотя это уже следующий пункт ниже, но всё же это важный контекст компании).
Перспективы профессионального роста (смогу ли я развиваться здесь профессионально?) – Этот пункт может не быть в вашем списке приоритетов, и тогда его можно пропустить. Однако, если вы планируете расти, а профессиональный рост обычно напрямую связан с повышением зарплаты (внутри одной или нескольких компаний), тогда стоит обратить внимание на существующие возможности в новой компании. А) Как я уже упоминал, один из критериев – это количество БА в компании. Небольшое количество может указывать на то, что рост будет ограничен из-за ограниченного опыта самой команды, а значит, со временем станет некому учиться. Но если в небольшой команде есть гуру БА, у которых можно учиться многие годы, то может возникнуть другой нюанс: небольшая команда, скорее всего, имеет ограниченный бюджет и ожидания по функциям. Если в вашей компании 10-15 БА, есть руководитель БА группы и два-три его помощника, то, возможно, компании не потребуется еще один руководитель, и, соответственно, рост с целью повышения зарплаты будет ограничен или очень растянут во времени (если только у компании уже нет четко определенных планов по расширению штата, включая БА, в краткосрочной перспективе). Б) Узнайте, как компания вкладывается в рост сотрудников: оплачивает ли она внешние курсы, имеет ли свою внутреннюю систему обучения, поддерживает ли практики по созданию продуктов и выполнению проектов. В) Зрелость процессов, связанных с должностными переходами: как происходит процесс перехода сотрудника на новую должность и повышения зарплаты.
Вот и все рекомендации по этой теме, и надеюсь, они окажутся полезными, особенно если вы планируете сменить место работы и ищете надежного работодателя на ближайшие 5-10 лет.
Прошу прощения за то, что так долго не могу закончить эту вводную главу – я понимаю, что читатель, вероятно, уже хочет узнать, чем же всё-таки занимается БА на начальных этапах карьеры! Однако, позвольте мне вставить ещё одну маленькую заметку перед окончанием истории, о самом важном вопросе, который, по моему мнению, каждый должен задать себе: «А зачем мне вообще работа БА?». Опираясь на свой опыт работы БА, я хочу упомянуть мотиваторы или причины, почему мне нравится эта профессия день за днём, неделю за неделей, месяц за месяцем, год за годом. Я выделяю два вида мотиваторов: внутренние и внешние.

Зачем становиться БА
Внутренние мотиватор – зачем это мне?
Идеальная пропорция Деньги-Рабочая нагрузка-Моя жизнь (Work-Money-Life Balance) – за последние 10 лет я работал только в двух ИТ компаниях, Netcracker и EPAM, и для меня это было фантастическое персональное удобство быть бизнес-аналитиком. Уровень оплаты по сравнению с рабочей нагрузкой и временем на личную жизнь – он идеален. Если рассматривать баланс Работа/Жизнь/Деньги как параметр, то я бы оценил его на 90 процентов удовлетворенности, оставив 10 процентов на дальнейшие улучшения.
Я планирую свой рабочий день и неделю так, как мне удобно. Могу один день работать 7 часов, а другой – только 4 часа, если хочу или если у меня есть важные личные дела. Могу работать из дома, кафе, другого города или с пляжа – мне нужен только мой ноутбук. Я знаю, что многие компании после ковида перешли на удаленный формат работы и также не имеют фиксированных часов работы, но я говорю именно про работу как БА. Именно в этой роли, на мой взгляд, существует 'дух свободы'. Конечно, всё это возможно при условии, что вы выполняете все задачи в срок и с должным качеством.
Мировой опыт – меня очень и очень привлекает и вдохновляет работа в международной компании на международных проектах. Это постоянное получение новых знаний, информации, опыта, навыков из различных источников. Масштаб проектов/продуктов позволяет приобретать международный опыт и личное понимание того, что 'Да! То, что я создаю, делается с использованием процессов и подходов, как это делается по всему миру разными компаниями/проектами/командами!?
Развитие личности ‘Создатель Решений’ – это потрясающее ощущение, когда я создаю решения, которые затем используют другие люди и компании, помогая решать различные проблемы и приносить доход. Иногда это может быть просто маленький элемент системы, но я всегда вижу и подчеркиваю связь с конечным продуктом – «да, я участвовал в создании этого». И это ощущение имеет накопительный эффект: годы создания продуктов и решений укрепляют мой опыт и достижения. Я говорю «создавал» намеренно, потому что в моем представлении мира, где создаются продукты, именно бизнес-аналитики играют ключевую роль. Они – это своеобразный процессно-артефактный мост, который соединяет желания клиента с конечным продуктом, при условии активного участия БА.
Например, в 2016 году я разрабатывал каталог (таксономию) продуктов для новой ИТ-системы крупнейшей телекоммуникационной компании в Эквадоре. Я не просто работал над системой, но и визуализировал взаимосвязь между конечными пользователями и моим вкладом. Если вы окажетесь в Эквадоре (или живете здесь) и купите сим-карту или телефон у компании Movistar, а затем зайдете в свой личный кабинет для изменения тарифа или добавления опций, увидите структуру продуктов и их характеристики, которые были созданы мной и моей командой. Это мое внутреннее ощущение удовлетворенности и гордости за свою работу – да, именно внутреннее! Уверяю вас, я не хожу по улицам и не кричу на каждом углу: «Это создал я!».
Второй момент, который хочу поделиться – я считаю, что есть такой навык, который можно назвать «создатель решений». Это не официальная роль или должность, а скорее навык, который формируется, когда вы, как БА, регулярно создаете решения различного масштаба. За последние 10 лет у меня накопился личностный набор характеристик и навыков, которые образуют этот увлекательный навык. Может показаться чрезмерно оптимистичным, но без оптимизма любая работа может превратиться в скуку и недовольство!
Внешние мотиваторы: как мир влияет на мою мотивацию?
Информатизация всего – особенно это ощущается сейчас, после того как человечество пережило ковид. Множество компаний, которые ранее уделяли мало внимания ИТ-проектам, теперь открывают департаменты и нанимают большие команды подрядчиков и сервисных компаний, чтобы автоматизировать, улучшить и цифровизировать все свои процессы, сервисы и продукты. Это, естественно, влияет на спрос на специалистов, и я вижу, что профессия БА сейчас очень востребована, хотя 8-10 лет назад многие клиенты даже не понимали, зачем нужны эти БА в командах по поставке решений. Осознание того, что БА востребованы в мире, конечно же, добавляет мотивации работать или стремиться работать в этой перспективной профессии.
Увеличение масштабов решений и требований к их качеству – с развитием ИТ-технологий, таких как 'облачные' решения, машинное обучение, 'большие данные' и аналитика, масштабы ИТ-решений у клиентов растут, и, соответственно, увеличивается процент возникновения дефектов. Бизнес-аналитики являются одними из ключевых участников проектных ИТ-команд, влияющих на качество решений. Это заметный мотиватор, особенно в сервисной компании, где я работаю. Когда я вижу проекты с 4-7 командами (20-40 человек), где набирают по 4-5 БА, клиенты и поставщики решений понимают, что каждая даже небольшая команда должна иметь БА, который полностью готовит требования и управляет их жизненным циклом для каждой части решения.
Проводники решений – это, можно сказать, обобщение предыдущих пунктов, но это важный внешний мотиватор. Я вижу, что БА рассматривается как ответственный человек и проводник решения для клиента и его представителей, для проектной команды поставщика решения. Все вопросы и решения обычно проходят через БА с самого начала создания проекта, когда еще только выясняются бизнес-цели клиента, до момента поддержки ИТ-решения после его запуска. К этому моменту БА обычно является тем человеком, который обладает самыми полными знаниями и историей о проекте или продукте.
Давайте рассмотрим спрос на профессию бизнес-аналитика, опираясь на данные, которые я нашёл в LinkedIn. Я не буду приводить актуальную статистику текущего года, так как читатель может самостоятельно это проверить. Однако, в качестве примера, возьмем статистику за 2019 год, где уже был виден значительный спрос на эту профессию.


Примечание автора: данные на английском языке. Перевод:
Software engineer – Инженер-программист
Project manager – Руководитель проекта
Business analyst/ Data analyst – Бизнес аналитик / Дата аналитик
Solution Architect – Архитектор решений
UX Designer – Дизайнер Пользовательского опыта

И если взглянуть на рейтинг навыков, то интересно отметить, что еще в 2020 году LinkedIn опубликовал следующую статистику: среди всех профессиональных навыков бизнес-анализ занимал шестое место. Это действительно потрясающе!



Примечание автора: данные на английском языке. Перевод:
The Skill Companies Need Most in 2020 – Навыки компании нуждаются больше всего в 2020 году.
Top 10 Hard Skills – Топ 10 “жёстких” навыков.
Business analysis – Бизнес анализ.

Вот и закончилась первая история, и я надеюсь, что она вам понравилась. Прежде чем мы "нырнем" в жизнь БА в последующих историях и главах, давайте подведем итоги.
Чему я хотел бы посвятить окончание этой истории? Трудоустройство, как процесс, может показаться не таким уж сложным, но подготовка, учет всех нюансов, перспектив и принятие правильных решений – это уже может занять время. Конечно, это применимо к любой профессии, но цель этой истории была в том, чтобы показать именно специфику трудоустройства бизнес-аналитика.

Вторая история о том, как может выглядеть начало карьерного пути БА
Как обычно, начну с вводной части, описывающей, что и как будет происходить в этой истории. С точки зрения описания навыков обычного бизнес-аналитика, эта история будет содержать основное описание. Поэтому, я добавлю дополнительный уровень структуризации и декомпозиции описательной части внутри истории – шаги. Теперь у нас есть главы, внутри которых располагаются истории, и внутри историй – шаги как базовые элементы движения вперед. В этой истории шаги будут отражать моё поэтапное развитие как ИТ-бизнес-аналитика на уровне обычного регулярного БА.
На каждом шаге я описываю свой профессиональный рост, задачи и активности, которыми я занимался. Также я подробно расскажу о навыках, которыми, по моему мнению, должен обладать бизнес-аналитик, и приведу практические примеры того, как и почему я применяю эти навыки и активности. После всех шагов я опишу и объясню жизненный цикл или взаимосвязь навыков и активностей, поскольку между ними должна существовать связь. Также дам рекомендации о том, когда и в каких ситуациях использовать те или иные навыки и активности.
Наконец, как обычно, я закончу интересным итогом по данной истории. А теперь немного контекста: о чём именно будут шаги и какая связь будет между моим развитием, описанными навыками и подуровнями бизнес-анализа.
Будет представлено четыре шага, чтобы равномерно распределить смысловую нагрузку:
– Первый шаг: Я опишу свой старт как БА в своей первой ИТ-компании, о чем я кратко уже упоминал в предыдущей истории. В это время я работал в роли помощника опытного БА, создавая небольшие фрагменты требований.
– Второй шаг: Здесь я расскажу о периоде, когда я уже 'набил руку' в работе с требованиями и начал действовать как самостоятельный БА, способный описывать и управлять требованиями по определенной функции системы.
– Третий шаг: В этом этапе я увеличил масштаб своей работы до уровня компонентов системы.
– Четвертый шаг: На этом этапе я уже работал как product owner, ответственный за компонент системы.
Если говорить о временных рамках моего становления как регулярного БА, то это примерно 1.5 года, с марта 2013 года до конца 2014 года. Затем последовал период, когда я еще не был официально старшим БА, но уже выполнял его функции. Это продолжалось еще 4-6 месяцев до второй половины 2015 года. Таким образом, мне потребовалось около двух лет, чтобы стать хорошим начинающим старшим БА или просто отличным БА.
Время, необходимое каждому человеку для развития навыков, всегда индивидуально и зависит от множества факторов, включая компанию, в которой работает человек, тип проекта или команды, используемую методологию, профессиональный уровень команды и так далее. Кому-то может потребоваться год, а кому-то – четыре года, чтобы стать высококвалифицированным БА, готовым к переходу на следующую позицию. Единственное, что одинаково для всех, это ожидания 'контекста' (проекта, продукта, внутренней или внешней команды) относительно уровня владения навыками БА, и это является 'контрольной точкой' для понимания собственного уровня. Моя книга – это именно та 'подсказка', которая помогает бизнес-аналитикам развиваться, понимая уровни и определяя навыки БА на основании моего опыта.
Теперь немного о уровнях в рамках позиции 'регулярный БА'. Первый и второй шаги я отнес к первому уровню БА, который я бы описал как 'стабильный и уверенный создатель требований'. Регулярный БА на этом уровне может свободно определить и задокументировать требования к конкретной функции системы – это его основная задача и требование к уровню. Я намеренно привязал два шага развития к этому уровню, поскольку на начальном этапе карьеры БА важно сосредоточиться на ключевом навыке – умении 'правильно' задокументировать требования. Что значит 'правильно', я объясню подробнее в описании этих шагов 1 и 2.

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

Третий уровень отражает уже зрелого регулярного бизнес-аналитика, который, возможно, уже частично выполняет обязанности старшего БА и готов к переходу на новую позицию или должность. Такой аналитик работает также как владелец компонента системы. Он понимает и может заниматься оценкой своих времени и трудозатрат, а также знает, как оценки проводятся на уровне проекта. Этот аналитик разбирается в плюсах и минусах различных методологий, является доверенным лицом проектной команды и клиентов. Кроме того, такой БА хорошо разбирается в подходах к выявлению требований, включая знания о фазе discovery, умеет адаптироваться к изменениям в требованиях и эффективно планировать своё рабочее время в соответствии с приоритетами задач. Уточню очень кратко термин 'Дискавери фаза' (Discovery phase), так как я буду использовать его довольно часто, хотя подробно мы коснемся этого только в конце книги. Простыми словами, Дискавери фаза – это обычно активность в специально выделенный временной промежуток для выявления самых первоначальных целей проекта или продукта, требований и границ планируемого решения. Это, как правило, самый первый этап любого проекта или продукта.
Зачем я написал про эти уровни внутри регулярного БА? Для меня важно показать с помощью этого относительного подхода к их определению, что нельзя просто рассматривать кого-то как обычного БА с конкретным набором навыков и опыта. Мы должны понимать, что уровни владения и виды навыков могут быть различны. Я использую 'относительный подход', потому что каждый может выбрать собственный способ разделения, и это всего лишь один из возможных вариантов. Один БА может только начинать писать качественные требования, в то время как другой уже полностью управляет жизненным циклом требований для конкретного компонента и фактически является почти старшим БА.
Итак, я описал, о чем будет эта история, из чего она будет состоять, и как я понимаю подуровни регулярного БА. Теперь мы погрузимся в самое главное и полезное – это те навыки, которые использует бизнес-аналитик. Единственное, что осталось уточнить перед этим – это определение навыка, типы навыков, связанные с ними активности и масштаб их использования в контексте бизнес-анализа.
Навык (или на английском Skill) – это приобретенная способность выполнять действия с определенным результатом, качеством и в соответствии с ожиданиями по времени и трудозатратам. Под приобретенной способностью мы понимаем усвоенный практический опыт и специфические знания, которые, благодаря накопительному эффекту, трансформируются в нашей памяти в структурированное хранилище алгоритмов или схем действий (не обязательно физических), которые мы эффективно применяем в соответствующих ситуациях или контекстах. Наличие приобретенной способности гарантирует ожидаемый результат и требуемый уровень качества этого результата.
Существует несколько типов навыков. В контексте бизнес-анализа мы в основном используем два типа: Hard skills (жесткие навыки) и Soft skills (мягкие навыки).
Жесткие или технические навыки – это навыки, относящиеся к конкретным задачам в определенной домене или области. Они чаще всего могут быть проверены и имеют четко описанные требования, которые позволяют оценить умение человека в этом навыке. Например, у повара основной жесткий навык – это приготовление ресторанных блюд. Этот навык относится к области кулинарии в контексте ресторанов, и мастерство повара может быть проверено на основе качества его блюд. Этот навык приобретается через изучение литературы, курсы и практический опыт – многократное приготовление различных блюд.
Мягкие навыки отражают наше личностное поведение и взаимодействие с другими людьми. Они не привязаны к конкретной задаче, но абсолютно необходимы для успешного выполнения любой деятельности, так как значительно влияют на качество и результативность работы, где мы применяем жесткие навыки. Например, рассмотрим повара: помимо его профессионализма в жестком навыке, успешный повар обязательно должен обладать мягкими навыками, такими как управление временем, чтобы блюдо было приготовлено в срок, и навыками лидерства и коммуникации, которые помогают наладить процесс приготовления блюд в ресторане со своей командой.
Уточнение от меня: описывая в следующих шагах навыки в контексте конкретного уровня или подуровня, я не утверждаю, что эти навыки являются требованиями к этому уровню. Это мои рекомендации о том, в какой период карьерного развития стоит усвоить определенный навык. Каждый человек уникален, как я уже упоминал, и развитие навыков также происходит индивидуально и в определенном контексте или обстановке.

Шаг 1 – начинающий БА
Мой путь в профессии бизнес-аналитика начался в марте 2013 года, когда я устроился в свою первую ИТ-компанию NetCracker, занимающуюся разработкой ИТ-продуктов для телекоммуникационных провайдеров. Сразу после присоединения к компании, я был включен в команду, создающую многокомпонентную систему поддержки бизнеса клиента. Благодаря моему опыту как конечного пользователя в области операционных систем и управления взаимоотношениями с клиентами (CRM), я начал работу над соответствующим компонентом под руководством ведущего бизнес-аналитика, который уже некоторое время занимался этим компонентом.
Этот опыт оказался чрезвычайно позитивным, поскольку с первых же дней меня вовлекли в решение реальных задач, несмотря на мой нулевой опыт в бизнес-анализе. В дополнение к проектным задачам, мне предоставили множество ресурсов для изучения самого продукта, его модулей, компонентов и используемой архитектуры. Также было важно ознакомиться с телекоммуникационными стандартами разработки продуктов.
Каждое утро у меня проходили созвоны с ведущим бизнес-аналитиком, который объяснял мне задачу дня и предоставлял примеры аналогичных уже решенных задач, чтобы я мог делать работу по аналогии. Это один из главных подходов бизнес-анализа: создавать новое, по возможности, на основании существующих артефактов или шаблонов. В процессе выполнения задачи я записывал все возникающие вопросы и дополнительно созванивался с БА, обсуждая их, иногда несколько раз в день.
Мы регулярно проверяли прогресс моих задач – иногда один-два раза в день, но обязательно на следующий день. Это важный принцип, который я по-прежнему использую в своей работе: никогда не ждать финального результата задачи для проверки качества. Обязательно нужно проводить промежуточные проверки, чтобы своевременно определить отклонения от ожидаемого результата, обсудить их и внести коррективы. Чем позже обнаруживается отклонение, тем дороже обходится его исправление – 'дороже' в любом смысле: в деньгах, времени, ресурсах.
После проверки выполненной работы, мой наставник давал мне комментарии и указания, что именно нужно исправить и почему. Например, он показывал уже готовый и подписанный клиентом артефакт и объяснял, почему такой способ документирования является наиболее эффективным. Теперь давайте рассмотрим, чем именно я занимался в первые дни и недели и как выглядел мой обычный рабочий день новичка в роли бизнес-аналитика
Мой рабочий день был разделен на две основные активности: коммуникация с ведущим БА и работа с требованиями. Также была третья дополнительная активность – изучение систем и стандартов компании и продукта, которой я занимался лишь эпизодически, и в основном в контексте текущих проектных задач. Я последовательно придерживаюсь одного подхода на протяжении последних десяти лет – приоритет отдаю реальным задачам, переходя к изучению нового только после того, как уверен в выполнении всех своих обязанностей в срок.
В течение первых четырех недель моя работа состояла в документировании описания и дизайна небольших частей функциональных требований системы. Упоминание «небольших частей» не случайно – моя задача заключалась в описании ограниченного объема функциональности системы, что было оптимальным решением, учитывая мой начальный уровень опыта. Это позволяло эффективно сотрудничать с моим ведущим БА, который предварительно набрасывал и обсуждал со мной основные элементы функции. Он также объяснял, какие бизнес- и функциональные требования у нас есть на входе и что ожидается на выходе, включая дизайн требований и ожидаемый уровень детализации.
Давайте подробно опишу распорядок одного из моих рабочих дней в этот период. В последующих историях я также покажу, как изменились мои рабочие дни с постепенным профессиональным ростом, а какие аспекты остались неизменными.
Я прихожу на работу обычно между 9 и 11 утра. Эта гибкость в выборе времени начала рабочего дня – один из замечательных плюсов работы в ИТ-компании, в отличие от традиционного бизнеса, где часто требуется быть в офисе строго к определенному времени, даже если нет срочных дел или совещаний. В первые недели такая свобода была для меня необычной, но я быстро оценил это как серьезный мотивирующий фактор для эффективной работы – важно использовать рабочее время для выполнения задач в установленные сроки.
Первым делом я всегда проверяю свой ежедневник, где перечислены все текущие задачи и их статусы. Мониторинг и планирование задач – это ключевой инструмент эффективной работы и управления временем. Я осматриваю задачи, требующие внимания, и определяю, какой из них я займусь в первую очередь. Проверяю наличие потенциальных препятствий или блокеров для выбранной задачи, которые могут требовать вмешательства других лиц. Если такие препятствия существуют, я стараюсь запланировать обсуждение с моим БА в удобное для него время. Я делаю это сразу, не откладывая до тех пор, пока не столкнусь с трудностями из-за блокирующих задач. Эффективное планирование звонков и ключевых активностей занимает всего 5-15 минут, но позволяет мне спокойно работать дальше, зная, что важное совещание уже запланировано
Вторая задача или активность в моем рабочем дне – это звонок с моим ведущим БА-ментором, который может быть утром или вечером. Как я уже упоминал, на начальных этапах карьеры крайне важно синхронизировать формат, план, процесс и ожидания от своих активностей с ответственным за весь проект. Мы обсуждаем мои достижения за предыдущий день, возникшие вопросы и планы на текущий день. Получив отзывы от БА, я приступаю к своим ежедневным задачам.
Особенно важно, по моему опыту, проводить звонки и совещания в первой половине дня, желательно утром, чтобы максимально эффективно усвоить полученную информацию. За мои 10 лет работы у меня сложилось понимание, подтвержденное исследованиями, что сложные мыслительные процессы наиболее эффективно выполняются в ранние часы. Чем дольше человек находится в рабочем процессе, тем труднее ему воспринимать сложную информацию и выполнять сложные задачи. Существует даже выражение «обсудим на свежую голову», подчеркивающее, что вечером обсуждение важных вопросов может быть неэффективным.
В контексте моих основных задач – звонков с ведущим БА и документирования дизайна – я стараюсь придерживаться этого подхода. Проведение звонков утром помогает мне максимально эффективно решать все вопросы и затем спокойно заниматься документированием. Если вечером мозг уже устал, завершить документацию становится гораздо проще, чем проводить активное обсуждение. Важно планировать так, чтобы на митинги и встречи приходить максимально собранным и эффективным. Это же правило применимо и к тем, кто работает с обеда до поздней ночи – принципы остаются теми же.

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

Создание требований
Рассмотрим бизнес-требование: «Профиль компании должен содержать информацию о кредитоспособности компании». Это требование от бизнеса и клиента ясно формулирует необходимость проверки платежеспособности компании-покупателя перед совершением коммерческих операций с предоставлением товаров в рассрочку.
На основе этого бизнес-требования я разработал функциональное требование: «ФТ-СУК-КР-1. Система должна предоставлять на главной странице профиля компании обобщенную информацию о кредитном статусе клиента, включая кредитный статус, кредитный рейтинг и текущие кредитные условия».
Давайте разберём идентификатор этого требования: «ФТ-СУК-КР-1». «ФТ» означает «Функциональное Требование». «СУК» указывает на систему, к которой относится требование – Система Управления Клиентами. «КР» обозначает конкретный модуль или компонент системы – Кредитный модуль. Номер требования – 1. Правила создания таких идентификаторов позволяют легко определить, о чем идет речь в требовании. Текст требования может быть изменен, но идентификатор остается неизменным и играет ключевую роль в матрице связей/отслеживания и в любых других документах, связанных с этим требованием. Функциональное требование включает в себя несколько важных пунктов, каждый из которых имеет ключевое значение:
«Система» – это кажущееся простое слово подтверждает, что именно наша система должна реализовать указанную функциональность. Это утверждение дает 100% гарантию включения функции в систему.
«должна» – ключевое слово, указывающее на обязательность поддержки функциональности системой, в отличие от формулировок «может» или «будет». Такая точность важна, так как любая неоднозначность может стоить значительных сумм, а разные трактовки могут использоваться как заказчиком, так и исполнителем.
«на главной странице…» – указывает на конкретное местоположение и содержание функции, что помогает точно определить, где именно будет реализована функция в интерфейсе.
«информацию о:…» – здесь конкретно перечисляются параметры, которые должна отображать система. Это может включать параметры, которые обязательно будут реализованы, а также те, которые могут быть добавлены позже, если это будет возможно в рамках проекта.
Таким образом, мы подробно описываем каждый аспект требования, обеспечивая его полную прозрачность и предотвращая возможные недоразумения в будущем. Так формируется функциональное требование.
Возможно, у вас возник вопрос: «Как, исходя из краткого и общего бизнес-требования, вы сформулировали такое детализированное функциональное требование? Откуда взялись детали о месте и содержании информации?». Часть ответа заключается в моем доменном опыте, о котором я упоминал ранее. Многолетняя работа в бизнесе и опыт использования различных бизнес-систем, которые обычно содержат похожий набор параметров и функций, позволяют мне предложить наиболее подходящий подход к информации о платежеспособности клиента для нашей системы.
Вторая часть ответа касается процессов, связанных с документированием требований. Помимо написания самого документа, в процесс включены коммуникационные действия, такие как обсуждение требований, их обновление и подписание. Написанное мной функциональное требование не будет сразу же переведено в дизайн. Сначала оно пройдет внутреннее обсуждение с моим ведущим бизнес-аналитиком, в ходе которого могут быть внесены правки. Затем следует обсуждение с клиентом, возможные дополнительные изменения и окончательное подписание требования. Только после всех этих этапов начнется документирование дизайна для этого функционального требования.

Дизайн требования
Получив подписанное функциональное требование, я приступаю к разработке дизайна, который описывается в документе, называемом "Спецификация по функциональному дизайну" (Functional Design Specification). Стоит отметить, что подходы, описываемые здесь, адаптированы под конкретный проект и могут отличаться в зависимости от контекста.
Как начинается процесс? Сначала я создаю уникальный идентификатор для дизайна, например, ФД-СУК-КР-1. "ФД" здесь обозначает "Функциональный Дизайн". Затем формируется короткое название дизайна, которое будет использоваться как заголовок документа, например, "Просмотр кредитной информации на главной странице компании". Функциональное требование может соотноситься как с одним, так и с несколькими дизайнами.
Описание дизайна:
"Описание: Данный дизайн позволяет пользователю видеть основные кредитные показатели компании-клиента на главной странице профиля. Эта информация помогает в принятии решений."
Входные условия:
Для использования функциональности пользователь должен авторизоваться в системе СУК, выбрать компанию и перейти на её главную страницу.
Описание функциональности:
Затем следует детальное описание функциональности, представленное в виде нумерованного списка. Этот список описывает шаги, которые система выполняет в ответ на действия пользователя. Подобная структура упрощает понимание логики работы системы и облегчает последующие обсуждения возможных корректировок.
Шаги/Сценарий:
На странице профиля компании система отображает раздел «Кредитная информация».
В разделе «Кредитная информация» отображаются следующие поля/данные:
Кредитный рейтинг (название) – текстовое, неизменяемое.
Кредитный рейтинг (значение) – неизменяемое, цифровое, двузначное число с поддержкой десятичного значения, диапазон значений от 0 до 10.
Кредитный статус (название) – текстовое, неизменяемое.
Кредитный статус (значение) – неизменяемое, графическое отображение в виде круга с тремя цветами: красный, желтый, зеленый.
Кредитные условия (название) – текстовое, неизменяемое.
Кредитные условия (значение) – неизменяемые, три текстовых поля со значениями:
а) разрешенная рассрочка: «ХХ» месяцев;
б) статус контракта: «активен», «неактивен» или «истек»;
в) размер задолженности: «нет» или «размер задолженности».
Кредитная история (название) – текстовое, неизменяемое, оформлено как ссылка (функциональность вне границ этого дизайна, см. ФД-СУК-КР-4).
Заключение:
Вот и всё – это описание основного блока дизайна для простой функциональности, чтобы избежать множественных страниц детального описания.
Изменение данных:
В данном дизайне изменение данных не предусмотрено, так как у пользователя нет возможности изменять представленную информацию.
Функциональный дизайн готов к использованию разработчиками, но работа здесь не заканчивается. В большинстве проектов важно, чтобы функциональность, предназначенная для пользователя, сопровождалась соответствующими визуальными и дата-компонентами. Это необходимо для того, чтобы команда разработчиков могла не только реализовать функциональность, но и визуально оформить её, а также обеспечить правильную работу с данными.
Для этих целей я разрабатываю два дополнительных документа:
Спецификация по пользовательскому интерфейсу (СПИ / 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 часов в год, которые я гипотетически могу потратить, как захочу.
В этом примере ключевой момент заключается в том, что время обладает гибкостью и всё зависит от того, как человек планирует своё время. Планирование – это важно. Одна из ключевых частей управления временем – это его планирование. Планирование времени включает в себя распределение времени на задачи – ежедневные, еженедельные, ежемесячные и так далее. Наша жизнь состоит из постоянных задач, и от того, как мы планируем обязательные задачи, зависит, сколько у нас будет свободного времени на необязательные задачи (например, отдых). Естественно, желательно, чтобы времени на отдых было как можно больше.
На работе, начав свою карьеру как бизнес-аналитик, я определил несколько целей для детального планирования задач: а) чтобы выполнять задачи вовремя, согласно установленным срокам; б) как следующий этап развития – стремление выполнять задачи быстрее установленных сроков; в) чтобы, как я уже упоминал, освобождать больше времени для необязательных задач. Важное уточнение по пункту «б» – это реальная цель, которую я всегда преследую и сейчас. Цель не просто выполнить задачу в срок, а так планировать свой день или неделю, чтобы выполнить задачу значительно быстрее установленного срока.
Когда я начал карьеру бизнес-аналитика, я задал себе вопрос: «Чем я могу выделиться среди других БА в нашей компании?». Одним из ключевых отличий, которое я выбрал, стал навык и подход к планированию. Оценивать свое развитие в этом направлении было довольно просто. После нескольких месяцев работы в качестве БА, продолжая совершенствовать свои умения, я помню случаи, когда ведущий БА поручал мне задачу по документированию требования, говоря, что на это уйдет примерно две недели. Я планировал так, чтобы завершить задачу за пять дней. Это была моя цель, и развитие этого навыка было прямо пропорционально увеличению моей ценности для компании. В будущем часто возникали ситуации, когда я соглашался участвовать в срочных проектах с очень сжатыми сроками, что я рассматривал как преимущество. Подробнее о таких ситуациях я расскажу в следующих главах.
Возвращаясь к управлению временем, этот навык важен и сложен одновременно, что делает его особенно значимым. Навык управления временем является сложным, так как работа бизнес-аналитика не подразумевает однообразных и четко определенных процессов – каждый проект и продукт уникален, и БА должен адаптировать свои подходы под каждую задачу. Под каждый проект и продукт нужно соответствующим образом управлять временем. БА должен уметь понимать контекст и эффективно управлять своим временем. Под «важен» я имею в виду высокую ценность и приоритет этого навыка и связанных с ним активностей. Вернусь снова к теме «планирования времени и задач» как к примеру сложности и важности этого процесса. Для меня это до сих пор самая значимая и сложная ежедневная задача. Пока я не запланирую свой день, я не приступаю к выполнению задач. Иногда мне приходится тратить 30, 60, а иногда и 90 минут просто на идентификацию, анализ, подготовку и планирование дневных задач, включая их приоритизацию и декомпозицию. Однако, когда планирование завершено и я точно знаю, что максимально эффективно организовал свое рабочее время, мне становится легко и прозрачно выполнять все запланированные задачи без малейшего сомнения. Детали, рекомендации и подходы мы рассмотрим в следующих главах. Может показаться немного сумбурно, но таковы мои размышления о навыке управления временем. Остается только один важный аспект, без которого описание этого навыка нельзя считать завершенным: описание того, что должен уметь человек, и какими способностями он должен обладать (по моему мнению), и всегда с уточнением «максимально эффективно» относительно активностей/задач/процессов: планировать, приоритизировать, декомпозировать/дробить, распределять/определять время выполнения, оставаться сфокусированным, делегировать, всегда видеть целевую цепочку, принимать решения. Кратко о каждом умении: Планирование – это начало любой активности вообще и включает в себя такие аспекты, как определение самого процесса и подхода к планированию в зависимости от контекста, разработка и документирование артефактов планирования, а также непрерывный мониторинг, проверка и актуализация плана. Непрерывная приоритизация активностей обеспечивает понимание и уверенность в том, что выполнение задач происходит с максимально эффективным использованием времени и приносит максимальную ценность для конечных целей. Приоритеты могут меняться со временем или быть статичными, но должен быть четко определен их порядок и критерии. При наличии прозрачного приоритезированного списка активностей/задач исключаются факторы сомнения о затрачиваемом времени на задачу – это важно как психологически, так и профессионально, поскольку когда я выполняю какую-либо задачу, у меня нет сомнений о её актуальности и полезности. Декомпозиция очень важна, особенно по мере вашего профессионального роста и, соответственно, увеличения сложности проектов/продуктов, в которых вы участвуете. Неправильная или недостаточная декомпозиция может привести к серьезным задержкам в выполнении задач и неэффективному использованию времени. Нельзя удержаться и не привести пример, с которым, я думаю, большинство из вас сталкивалось как в рабочих, так и в личных делах. Вот пример из внерабочих активностей, основанный на реальных событиях: скоро день рождения у моей жены, и у меня есть задача «Поздравить с днем рождения». Для этой активности, естественно, может быть очень простой план без какой-либо декомпозиции, который выглядит как «Поздравить с днем рождения = купить подарок» и всё готово. Или можно подумать и сделать декомпозицию, например, на три пункта: 1. Подготовить поздравление. 2. Подготовить подарок. 3. Определить место для празднования. Эти три пункта, в свою очередь, содержат подпункты. Например, пункт №1 может включать: 1. Придумать сценарий поздравления. 2. Закупить необходимые материалы. 3. Подготовить части поздравления. Каждый из этих пунктов можно далее декомпозировать. Например, пункт №2 разбить на подпункты: 1. Материалы для подготовки видеопоздравления. 2. Материалы для оформления стола. 3. Контекстные материалы. Из этих я еще сделаю разделение, например, для пункта 3 на: надувные шары, фотографии для украшения стен, коробки для подарков, упаковочная бумага и так далее. И вот после всех уровней декомпозиции у меня есть довольно простые задачи, которые я могу запланировать выполнить в уже примерно понятные временные сроки и даты. Да, тут нет ничего сверхъестественного, и всё действительно просто – именно в этой простоте декомпозиции кроется сверхэффективность. Декомпозиция позволяет концентрироваться на конкретной, понятной и выполнимой в краткосрочной перспективе задаче или активности. Следующее умение, связанное с распределением и определением времени, выделяемого на какую-либо задачу, думаю, не требует объяснений, так как в большинстве случаев любая глобальная активность или цель всегда имеет временные рамки. Соответственно, любые ваши действия, чтобы рассматриваться как эффективные с точки зрения времени, должны быть оценены: сколько времени они займут и когда наиболее правильно будет их выполнить. С умением «быть сфокусированным» тоже всё просто и важно. Включая упомянутые выше умения, такие как приоритизация, планирование и декомпозиция, у вас должна быть ясная картина, чем и когда заниматься. Затем важна личная способность а) быть сфокусированным на одной задаче в данный момент времени (никакого мультитаскинга), и б) всегда иметь в фокусе общую картину глобальной цели, когда вы тратите своё время на конкретную активность.Следующая способность, "делегирование", подразумевает, что вы понимаете и распределяете задачи среди коллег, чётко осознавая, какую пользу это принесёт в контексте затрат времени и ценности для конечных целей. Если вы работаете в команде бизнес-аналитиков, то не должно быть сценариев, когда вы пытаетесь взять на себя все важные, сложные или крупные задачи, ведь у вас также есть умение декомпозировать, которое может помочь распределить задачи внутри команды. Также у вас обязательно будут активности, зависящие от внутренних и внешних факторов – у вас должно быть понимание и подход, в каком формате, как, зачем и с какими ожиданиями делегировать задачи другим.
"Видеть целевую цепочку" – это навык, который требует практики и опыта. Я бы описал его как способность быть сфокусированным – в любой момент и при любых обстоятельствах вам должна быть ясна связь от начальной стадии до конечной цели всех задач и проектов. Если я вношу изменения в одно поле на странице веб-сайта, я должен понимать, как это повлияет на один из бизнес-процессов, в рамках которого используется этот веб-сайт, что в свою очередь влияет на результаты работы нашей команды. И последнее умение, которое звучит удивительно просто – умение принимать решения. Да, именно это умение напрямую влияет на эффективное использование времени. Колебания в принятии решений не допустимы. Это особенно просто, если всегда помнить и повторять себе, что откладывание или избегание принятия решения (что ведет к задержкам и, следовательно, к неэффективному использованию времени) можно преодолеть, напоминая себе: «В принятии решения всегда есть опции, из которых надо выбрать. С любой выбранной опцией я продвинусь вперед. Если что-то пойдет не так, я всегда смогу принять следующее решение, и это нормально». Таков подход. Не должно быть ситуации, когда мы говорим: «Я пока не могу принять решение», особенно если все перечисленные выше умения уже применены и использованы. Применение описанного подхода минимизирует любые сомнения. Вот и всё, что я хотел сказать про навык тайм-менеджмента; описать его не так уж и просто, но я постарался.
Это всё, что я хотел рассказать о своём первом шаге на пути карьерного развития. Если кратко обобщить вышесказанное в 3-4 предложениях, то поделюсь следующим: первый стартовый этап освоения базовых навыков и понимания формата работы бизнес-аналитика занял у меня примерно два месяца. В это время я сосредоточился на жёстких навыках, таких как документирование требований и дизайнов к ним, а также изучение базовых процессов выявления требований, понимание структуры требований и дизайнов, определение критериев готовности. В сфере мягких навыков акцент был сделан на управлении временем, умении задавать вопросы и, конечно, командной работе.

Шаг 2 – отличный БА.
На этом этапе я продолжаю работать с требованиями, уделяя больше внимания различным аспектам управления требованиями и стремясь принять на себя больше ответственности и самостоятельности для полноценного документирования функций системы. Теперь всё это происходит уже не под столь пристальным вниманием моего ментора – ведущего бизнес-аналитика.
Через пару месяцев мой проектный БА оценил развитие моих навыков и способности, и уже стал доверять мне документирование требований и дизайнов целых функций компонента системы. Это было несказанно радостно – ощущение, что ты создаешь что-то целостное от начала до конца, которое я описывал ранее, только усилилось.
Что же такое функция? Возьмем пример из предыдущего этапа: у нас есть компонент системы под названием “система управления информацией о клиентах”. В этом компоненте существуют различные функции, такие как создание профиля клиента, редактирование профиля, просмотр и управление кредитной информацией о клиенте и многие другие. Каждую такую функцию можно далее разделить на множество подфункций или требований. Одно из требований, касающееся кредитной информации, мы уже рассмотрели на предыдущем шаге. Функция представляет собой определённый набор свойств и действий (как пользователя, так и системы), которые позволяют конечному пользователю выполнить полноценное и завершённое действие с определённым ожидаемым результатом. Как я упоминал ранее, например, функция "создать профиль клиента".
С течением времени я начал получать задачи по подготовке функций. Виды задач, активности и ответственность стали разнообразнее, что отражало мой продолжающийся профессиональный рост. Я ощущал, что уровень сложности моих задач повышается: теперь задача заключалась не просто в написании требований и их документировании. Теперь мне требовалось анализировать нужную функцию, декомпозировать её, определять и документировать необходимые требования и дизайн, корректно связывать все требования между собой в матрице требований, управлять статусом готовности и блокерами, а также подготавливать вопросы для заинтересованных сторон (stakeholders) со стороны клиента. Да, это был настоящий взрыв нового опыта! Как следствие, к задачам, связанным с функциями, добавились общие профессиональные задачи в связи с увеличившейся сложностью: проверка и поддержание (а при необходимости изменение) информационной модели/структуры требований и дизайна, поддержание их логичности, понимание работы с моделью данных, разработка спецификаций модели данных, понимание жизненного цикла разработки системы, а также развитие дополнительных и необходимых "мягких" навыков. Столько всего… наверное, я сразу «раскрыл карты» о навыках и активностях, которые буду дальше описывать, но так вот – никаких секретов! Единственное, я упомянул новое слово «стейкхолдер». Поясню: стейкхолдер – это человек, который ожидает и будет иметь какую-то выгоду от ИТ-продукта, который я создаю, или будет его использовать. В проектах компаний-поставщиков сервисов или продуктов, которые нанимают другие компании, основными стейкхолдерами всегда являются люди на стороне клиента, те, кто ожидает готовый продукт. Это может быть всего один человек, взаимодействующий с сервисной компанией, или множество людей на стороне клиента. Это люди разных уровней в организации клиента – от генерального директора до заместителя директора ИТ-департамента, экономического отдела или отдельной проектной команды, курирующей создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. Именно с ними БА выявляет требования к системе/продукту. Позже мы подробно рассмотрим БА-навык «управление стейкхолдерами».
С точки зрения процессов и активностей, у меня уменьшилось количество времени, которое я выделял ежедневно на обсуждения со своим ведущим БА, так как он стал более уверен в моем умении документировать требования и в моей профессиональности в целом. Иногда у меня даже не было ежедневных созвонов. Но вместо этого появились серьезные, хоть и нечастые, созвоны, где мы обсуждали мою подготовку документации по всей функции. Для описания активностей и навыков я возьму функцию, которой я занимался, – «Управление адресной информацией», которая является частью компонента «Система управления информацией о клиенте». Мне было поручено полностью подготовить необходимые дизайн-спецификации для разработки этой функции. Сначала мне нужно было прояснить бизнес-цели создания и понять, какие входные данные у меня есть. Единственным моим источником был мой ведущий БА, который работал и общался с командой клиента для выяснения любых вопросов. Я запланировал с ним звонок и начал готовиться к обсуждению. Заранее подготовил список вопросов, которые помогли бы мне определить границы задачи и прояснить неясные моменты. Я проверил существующие бизнес-требования, упоминавшие что-либо о адресной информации, и включил их в свой вопросный список, чтобы подтвердить, какие из них будут использоваться для создания функциональных требований. Я сделал черновую декомпозицию функции на набор предварительных функциональных требований.
Декомпозиция началась с базовой функциональности по созданию, редактированию, просмотру и удалению адреса. Затем я подумал, что поскольку система предназначена для бизнес-клиентов, они наверняка могут иметь несколько адресов. Поэтому я добавил требования по управлению списком адресов. Очевидно, потребуются требования к работе с полями/параметрами создаваемого адреса: какие поля доступны, каковы их свойства и типы. Например, некоторые поля – это простые текстовые поля, а другие представляют собой список, из которого можно выбрать только одно из предопределённых значений. Также я включил функциональность различения типов адресов – например, физический адрес и адрес для выставления счетов, при этом основные адреса могут отображаться также на главной странице профиля клиента. Плюс такого подхода к декомпозиции, прежде чем начать писать детальные требования и дизайн, заключается в том, что ты уже разделил одну большую задачу на несколько и можешь выбирать, с какой лучше начать. Когда начинаешь работу, ты уверен, что не будет пересечений в разных активностях, которые могут привести к необходимости постоянно переделывать уже готовые артефакты (требования, дизайн и т. д.). Теперь можно было и обсудить всё с моим БА.
На звонке мы определили, какие вопросы БА должен прояснить с клиентами, так как, например, были неясности в бизнес-требованиях, которые по своей природе не должны быть детализированы. Также я получил ценное замечание, о котором совсем не подумал – об интеграции моей функции с существующей в нашем продукте системой управления адресами. Поскольку адреса используются во множестве модулей/компонентов, у нас есть отдельный компонент, предназначенный для этой цели. Мы обсудили необходимость создания карты интеграционных связей между элементами, а также необходимость мне изучить нашу существующую систему управления адресами. Последним пунктом обсуждения стали первые требования из декомпозиции, которые были наиболее понятны и которые можно было начать документировать. В результате звонка появились задачи для каждого из нас, которые нужно выполнить в определённые сроки. БА попросил меня также прислать итоги нашего звонка в письме. Как всегда, любое обсуждение планируемых задач с коллегой оказалось очень полезным – это большой плюс работы в команде, даже если команда маленькая. В течение 30 минут после звонка я отправил митинг-ноутс (Meeting Notes) в письме, где включил информацию о том, что мы обсудили, кто и что должен сделать и когда. Хочу сделать акцент на этом фантастически полезном и ценном артефакте – «митинг-ноутс», который я использую в своей работе в ИТ уже 10 лет и везде, где это возможно. Почему фантастически? Потому что этот артефакт помогает мне структурировать планы мои, команды и клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу договоренностей, указанных в этих записях; определить ответственные стороны и сроки выполнения; и является самым надежным коммуникационным каналом для сохранения информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то очень сложно изменить эту информацию. Я лично всегда отправляю митинг-ноутс, даже когда меня никто об этом не просит. Это дает мне 100% уверенность, что информация донесена всем, даже если на самом совещании кто-то был не вовлечен по каким-либо причинам; такой человек может потом найти время и прочитать митинг-ноутс позже. И за свою карьеру у меня было множество случаев, когда этот артефакт спасал от масштабных проблем или споров на разных уровнях менеджмента между клиентами и моей компанией. Например, когда речь идет о финансах, и кто-то на стороне клиента упустил важный пункт, который был указан в митинг-ноутс, этот человек может пытаться убеждать на словах, что чего-то не было или что-то было неправильно понято. Однако, пересылка участнику митинг-ноутс письма шестимесячной давности, где он был в числе получателей и согласился со всем предложенным, решает проблему положительно почти всегда. Я приведу небольшой пример митинг-ноутс, который отослал, чтобы показать именно структуру митинг-ноутс письма – простую и очень эффективную.
Письмо, которое я отправил своему БА:
Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»
Тело письма: «
Обсудили:
Требования к новой функции
Требования, которые можно брать в работу
Требования, которые нужно прояснить с клиентом (номера требований)
Экшн айтем (action items – пункты действий):
Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)
Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.
Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.
Дополнение: допиши если я что-то упустил.»
Вот такое короткое письмо, из которого каждый понял, что от кого и когда требуется. Очень рекомендую его использование в любых ситуациях и для любой аудитории. Естественно, уровень детализации и стиль написания зависят от типа целевой аудитории. Если это менеджерское совещание, то формат должен отображать только суть, простым и понятным языком. Если же это созвон с техническими командами и проектными менеджерами, то можно и нужно описать детально принятые решения с техническими ключевыми моментами и детальным планом действий. Если есть сомнения в правильности понимания каких-то пунктов, то перед отправкой митинг-ноутс очень рекомендую напрямую уточнить у нужного человека, что именно имелось в виду. Если доступа у вас нет или прояснение невозможно, потому что клиент сказал что-то, что вы поняли, но возможно не на 100% правильно, то в самих митинг-ноутс обязательно нужно указать или оставить примечание к неясному пункту: «Пожалуйста, поправьте или дополните этот пункт, если есть неточности», и можно также упомянуть конкретного человека.
Затем я занялся документированием уже финального варианта функциональных требований, которые были готовы к просмотру клиентом. Я определил, в какой документ включить блок требований, и какой формат нумерации использовать. Формат нумерации я уже упоминал ранее и обсудил полезность этого уникального номера требования, который впоследствии может использоваться при обсуждении с членами команды или клиентом. При просмотре требований он позволяет сделать удобные ссылки на конкретное требование, без необходимости цитировать его полностью. Например, требование имеет номер ФР-СИМ-СИД-02. Клиент при проверке требований может сделать замечание: «Требование ФР-СИМ-СИД-02 не понятно, следует добавить детали». В плане формата требований я старался следовать простому правилу – стараться уместить требование в одно предложение, написать его в максимально простой форме. У меня было черновое требование, которое звучало как: «Должна быть возможность создавать адрес для клиента, заполнять необходимые поля и редактировать их при необходимости». Я разбил этот черновик на следующие требования:
– «Система должна предоставлять возможность создать адрес для клиента»
– «Система должна предоставлять возможность редактировать адрес для клиента»
– «Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.»
Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса. В этом случае, возможно, потребуется изменение только одного требования, в то время как остальные два уже будут утверждены. Этот пример, конечно, условный и масштабируемый – у меня было 50, 100 и даже 300 таких требований, и их простота и самодостаточность обеспечивали эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а другую часть – как требующих прояснений.
После подготовки всех функциональных требований я проверил, что все они имеют связи в матрице отслеживаемости требований. На тот момент я контролировал наличие связей между бизнес и функциональными требованиями. Я проверял, чтобы каждое функциональное требование соответствовало по крайней мере одному бизнес-требованию, то есть чтобы не было «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. Также я проверял, чтобы не было бизнес-требований, которые не указывают на какие-либо функциональные требования, т.е. чтобы я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал несколько комментариев. Я внес правки и, в итоге, функциональные требования были отправлены на просмотр и утверждение клиенту.

Утверждение требований
Вы, возможно, сейчас задаете мне вопрос: «Зачем их отправлять, если уже обсудили бизнес-требования и понятно, что нужно делать?» Тут всё просто – каждый проект имеет контекст, который позволяет определить критерии, по которым просмотр и утверждение требований требуется клиентом или нет. В моем случае было несколько критериев: 1) это был проект, использующий водопадную методологию разработки, когда сначала подготавливается абсолютно вся документация, прежде чем начать создавать продукт/систему разработчиками. Соответственно, очень важно с самого начала определить даже на функциональном уровне, что хочет клиент. 2) Проект имел конкретные сроки, в которые мы должны были создать продукт. Поэтому именно утверждение клиентом требований позволяло быть уверенным и застрахованным от рисков изменения требований при старте разработки, так как утвержденные клиентом требования уже не могли быть изменены.
А в целом это моя рекомендация и очень полезная практика – без привязки к критериям, всегда иметь процесс утверждения требований, который в дальнейшем спасет вас от рисков и проблем в середине проекта, когда клиент вдруг решит, что создается не та система, которую он хотел. У меня было в будущем достаточно ситуаций, когда моя настойчивость в утверждении требований спасала от финансовых потерь со стороны моей компании-поставщика продукта. Например, клиент подписывал требование, а уже во время разработки продукта через 6-8 месяцев внезапно приходил какой-то другой представитель клиента и говорил: «Нет, это так не должно работать – меняйте на вот такую логику». В ответ на это мы доставали подписанный документ его же компанией и сообщали, что любые изменения будут делаться только через запрос на изменение, который будет стоить денег. И тут хочу упомянуть еще один важный момент – когда вы пишете функциональное требование, в котором описано парой слов, что «можно указать номер дома», это может показаться не важной деталью системы. Но когда в середине проекта придет клиент и скажет: «Ой, забыл, допишите еще номер дома, блока или промышленной зоны», тогда вы оцените влияние этого изменения, и оно, возможно, будет стоить десятки тысяч долларов для клиента, потому что, чтобы добавить информацию о промышленной зоне, нужно будет изменить визуальный интерфейс приложения, модели хранения данных, интеграционный интерфейс и возможно даже сторонний модуль адресов. И тогда вы подумаете: «Ох, как хорошо, что я утвердил функциональные требования с клиентом!» И естественно, я не имею в виду вербальное утверждение (просто в разговоре с клиентом). Я говорю о документальном утверждении – через электронную почту, в электронной системе управления разработкой/задачами или подписании бумажного документа.
Пока я ждал утверждения или комментариев от БА по итогам обсуждения списка функциональных требований с клиентом, я сосредоточился на написании дизайна к требованиям. Дизайн выглядел примерно так же, как я уже описывал на первом этапе, поэтому не буду еще раз описывать, что я делал. Я старался постоянно улучшать качество дизайна. Но вот завершая первый же дизайн, я столкнулся с новой интересной задачей.
Как вы, наверное, помните, в примере дизайна функционального требования последним пунктом я описывал раздел "изменение данных". Когда я написал дизайн к своему первому функциональному требованию по адресной системе и дошел до этого раздела, то я задал себе вопрос: «А какие данные и где будут меняться?» И я понял, что у меня появилась новая задача, отличная от тех, что были, когда я просто помогал своему БА создавать дизайн функций в существующем компоненте. Отличие проявилось в том, что теперь я занимался созданием компонента (Адресная система) «с нуля», и соответственно никакой модели данных в данный момент не существовало вообще в системе и никто о ней не знал. Я понял, что это я тот человек, который ее должен создать. То есть буквально взять приложение для моделирования данных и начать ее рисовать, а затем перевести в общепринятый формат документа.

Моделирование требований
«Пойду» по порядку: что такое эта модель данных в общем и в контексте ИТ-системы? Как следует из этого словосочетания, это данные, которые замоделированы для определенной системы. На данных строится абсолютно любая сущность в нашем мире. Любые данные состоят всего из трёх типов сущностей: это объекты, их свойства и связи (типы связей) между объектами. Возьмем простейшую модель данных – обычная книга. В модель данных входят объекты (я пишу вот прямо сейчас и генерирую мысли-примеры из головы): лист книги, сама книга, обложка, клей для склейки обложки и листов, краска для нанесения текста, сам текст. У объектов есть свойства, берем, например, обложку и ее свойства: это – тип материала, цвет, толщина/жесткость, вес. И обязательно между объектами одной системы должны быть связи (типы связей) – текст обязательно связан с листом и обложкой и не может существовать без них. Этот тип связи простым языком называется «отец-ребенок», так как текст/ребенок не может существовать сам по себе как часть книги без листа или обложки/отца. Вот такая модель данных книги у нас получилась. Формат, в котором я это описал, также называется объектно-ориентированным моделированием (которое логично перетекает в объектно-ориентированное программирование).
Почему наличие или создание модели данных важно при подготовке такой вещи, как книга или любой системы? На примере книги я бы построил такую логическую цепочку, и всё выглядит довольно прозрачно:
1.Цель создания почти любой сущности в нашем мире – это её использование человеком.
2.Использование человеком означает использование функций предмета или системы.
3.Функции предмета или системы – это как раз та функциональность, которую мы также опишем для системы или для книги. Для книги главная функция – это «читать книгу».
4.Но чтобы читать что-то, нужно иметь этот предмет или систему физически, то есть должно быть описание и модель того, как будет выглядеть книга и из каких объектов она будет состоять.
5.К тому же, все части книги должны иметь правильные свойства. Представьте, если из нашего примера мы укажем свойство «вес» для объекта обложки равное 30 кг? Вряд ли такую книгу будет возможно читать!
6.Также все объекты должны быть связаны между собой правильными связями. Мы ведь не хотим, чтобы страницы были склеены между собой, а текст указан только на обложке, а не на листах книги.
Из этого примера, я думаю, становится видно, что невозможно планировать детальное описание функций чего-либо без создания модели данных. От модели данных зависит корректность создания функционального дизайна, дизайна пользовательского интерфейса, разработки кода и возможностей системы для конечного пользователя. От согласованности и логичности созданной модели данных в дальнейшем будет зависеть расширяемость системы и её адаптивность к изменениям. Именно с помощью создания модели данных можно корректно оценить интеграционные возможности между разными системами, ведь в любой интеграции основную роль играет правильная синхронизация информации между двумя системами. Информация равна данным.
Какие инструменты я использовал для создания модели данных? Я использовал профессиональную программу для моделирования/проектирования, Архитектор Корпорации (EA = Enterprise Architect), для создания модели. В настоящее время доступно множество более простых программ, о которых я расскажу позже. В EA я создавал всю модель, а затем экспортировал её в обычный документ Word, который можно было переслать кому нужно – БА, разработчикам или клиенту для ознакомления. Также функциональность EA позволяет автоматически генерировать этот документ, который является частью дизайна системы. Что интересно, EA позволяет выгружать созданную модель непосредственно в код, создавая необходимые объекты, связи и их свойства прямо в нужном месте в кодовой базе у разработчиков.
Вот как выглядел процесс создания модели в общих чертах: я пересмотрел функциональные требования и начал проектирование объектов адресной системы. Естественно, основным объектом был «адрес». От этого объекта, например, наследовались такие объекты, как «адрес офиса» и «юридический/биллинговый адрес». «Наследовались» здесь означает тип связи между объектами, при которой нижестоящий объект наследует все свойства вышестоящего объекта и дополняется своими уникальными свойствами.
Если объект «адрес» включал атрибуты, такие как «улица» и «номер дома», то я предполагал, что «адрес офиса» также будет иметь эти атрибуты. Для атрибутов я также определял свойства, например, тип атрибута (число, текст или список значений) и его обязательность для заполнения, то есть он не мог быть пустым.
В процессе проектирования модели я сверялся с требованиями и делал пометки в черновом функциональном дизайне. Например, если я описал заполнение какого-то поля как текстовое, а при создании модели понял, что это будет список значений. В итоге у меня был готов документ по модели данных, который я также отправил на проверку своему БА, как и функциональный дизайн, созданный на основе этой модели.
Дизайн модели данных я также проверял на логические связи с матрицей требований. Этот артефакт был так же важен для подписания с клиентом, как и функциональный дизайн: все необходимые функции должны быть указаны, а также все необходимые объекты, их связи и свойства. Некоторые изменения в модели могли быть очень дорогими и значительно сложнее, чем изменение какой-либо функции системы. В своей дальнейшей работе, особенно при создании систем с нуля, я почти всегда создаю модель данных – и даже если модель данных не является официально требуемым артефактом, я создаю её для себя, чтобы быть на сто процентов уверенным, что я ничего не упустил.
И в заключение темы модели данных хочу поделиться примером простейшей модели по системе «книга», которая, например, могла бы пригодится при создании системы по управлению публикацией книг.


Примечание автора: названия в диаграмме даны на английском языке. Перевод: Book – книга ; Weight – вес ; Size – размер; Carton type – тип картона; Cover – обложка; Picture – изображение; Title – заголовок; Subtitle – подзаголовок; Pages – страницы ; Number of page -номер страницы.

Это только короткий пример, который визуализирует то, о чем я рассказывал несколько страниц назад. Я показал три основных объекта: книгу, обложку и страницу. Книга связана с объектами обложка и страница связью "родитель-ребенок", что означает, что эти нижележащие элементы всегда будут созданы именно под "родителем". Также объекты содержат базовые атрибуты, такие как вес или размер книги, и название обложки.
Вот так я и закончу описание первых двух шагов своего становления как БА. Да, было много разноплановых активностей, но как я всегда рекомендую и ожидаю от БА, самая главная и всегда востребованная черта любого начинающего БА – это его способность писать высококачественные требования и дизайны к ним. Именно эти артефакты прямолинейно связаны с нуждами команды разработчиков и от них зависит успех создаваемой системы. За прошедшие около 6 месяцев, что я проработал впервые в жизни как БА, я получил опыт и освоил навыки написания требований и дизайна к ним, создания модели данных, подготовки структуры требований, базовых навыков выявления требований, основ отслеживаемости и подходов к утверждению требований, основ методологии и жизненного цикла разработки, а также важные мягкие навыки, такие как командная работа, управление временем и вопросник.

Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/book/mihail-bahrah/biznes-analiz-ot-a-do-ya-gid-dlya-nachinauschih-70131448/chitat-onlayn/) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.