Читать онлайн Бизнес-анализ от а до я: гид для начинающих бесплатно

Кратко обо мне, бизнес-анализе и книге

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

О бизнес-анализе в сфере информационных технологий. Что такое бизнес-анализ и работа бизнес-аналитика в ИТ? В одном коротком и простом предложении я бы описал это так: Основная цель и активность ИТ бизнес-аналитика и бизнес-анализа – это создать информационную систему/продукт, который действительно хочет бизнес. Я это говорю не с практической или теоретической точки зрения, а с точки зрения моей идеологии, которой я следую, когда работаю. Работаю = создаю продукт (да это может быть только небольшая часть системы, но это часть системы), который будет приносить пользу кому-то (компания, человек). И я специально упомянул идеологию, потому что на теоретическом и практическом уровне есть множество вариантов и направлений и объяснений, чем занимается бизнес-аналитик в ИТ и что есть бизнес-анализ. Все они верны, но мне всегда важно, чтобы я понимал, что я создаю что-то для кого-то. Какую бы работу я ни выполнял, я всегда чётко вижу связь между даже самой маленькой технической задачей, которую я делаю и финальной бизнес-целью, той системой/продуктом, которую получит бизнес клиента. В жизненном цикле создания информационной системы могут участвовать множество людей, которые выполняют разные функции и имеют разные цели, но именно бизнес-аналитик должен брать на себя (пусть даже не официально) ответственность за поставку системы, которую хочет бизнес. С каждым годом всё больше и больше клиенты понимают и соглашаются, что им нужен помощник на стороне поставщика информационной системы, кто будет представлять их интересы в создании той системы, которую клиент хочет. И лучшим кандидатом на роль такого помощника я считаю бизнес аналитика. Кстати, интересный факт, опубликованный сайтом LinkedIn в 2020 году: бизнес-анализ попал на 6 место в списке самых востребованных навыков в ИТ.

Про книгу. Книгу я решил написать, чтобы поделиться своим опытом с теми, кто хочет только начать свой путь как ИТ бизнес-аналитик и хочет посмотреть, как этот путь может выглядеть. Так же поделиться своими знаниями с теми, кто уже работает бизнес-аналитиком, но также хочет получить дополнительные идеи для роста и развития. Вся книга написана исключительно на основании моего практического опыта и с описанием реальных ситуаций и задач и как я их решал. За 10 лет работы я почти не пользовался никакими теоретическими источниками/книгами в своей работе – исключительно свой собственный опыт и обязательно работа с наставниками – теми людьми, которые простыми словами знают больше и лучше в бизнес-анализе, чем я, в момент моего взаимодействия с ними. В книгах я логически разделил основные главы на должностные/профессиональные уровни бизнес-аналитика такие, как бизнес-аналитик, старший бизнес-аналитик, ведущий бизнес-аналитик, руководитель группы бизнес-аналитиков. Все эти пути я уже прошёл и это было потрясающее путешествие! На основании своего практического опыта и понимания я описываю те навыки, которыми на мой взгляд должен обладать БА на каждом из уровней. Я постарался не использовать “книга-учебник” подхода и больше сделать формат повествования, какой мы привыкли видеть в художественных книгах. Будет интересно!

Сейчас, кроме своих основных обязанностей, я так же являюсь владельцем каталога навыков и системы по построению карьерного пути для более чем 3000 бизнес-аналитиков в моей компании. Поэтому дальнейшее содержание книги с точки зрения полезности, не должно вас  подвести – мой опыт за этим проследил!

Вводная

О чем эта книга? С практической точки зрения – это описание старта БА карьеры с реальными примерами. С профессиональной точки зрения – это описание, а что же именно ожидается от регулярного БА – какие навыки, знания и опыт в современном ИТ мире. С литературной точки зрения – мои личные впечатления от трудоустройства и работы как БА, не имея никакого ИТ опыта, а также об осознании, что я стал отличным БА. Каждая глава разделена на смысловые истории. В первой истории я расскажу, как попал в ИТ сферу, с какими нюансами столкнулся при трудоустройстве, а также какие критерии следует учитывать при выборе места трудоустройства. Ведь именно от изначального выбора трудовой окружающей среды будет зависеть, как быстро вы сможете вырасти профессионально в бизнес-анализе и насколько опыт, который вы будете получать будет действительно актуальным и востребованным как внутри компании, так вне компании (на рынке труда).

Во второй истории я опишу, как начиналась моя трудовая деятельность как Бизнес-аналитик, на каких навыках я делал и рекомендую делать акцент, о какие “камни” я “набил шишки” (lessons learnt)/ошибки и как построить свою работу эффективно (ведь иначе и не должно быть у БА). Я расскажу про инструменты, которыми я пользовался (и пользуюсь), и которые увеличивают эффективность выполняемых задач. Это будет большая история, где мы начнем с описания новичка БА, который шаг за шагом развивается до БА, который уже становится старшим БА. Так же ПОСЛЕ прочтения книги вы можете в оглавлении легко переходить на описание нужных навыков – я указал описание навыков как пункты оглавления для удобства читателя. Начинаем! Хотя…чуть не забыл одно важное уточнение: под словами “бизнес-анализ”, “бизнес-аналитик” или “БА” в этой главе и во всей книге я подразумеваю ИТ БА(IT BA) – бизнес-анализ/бизнес-аналитика по информационным технологиям(ИТ)/системам. Простым языком про “Информационные технологии/системы” я бы сказал так – это программное обеспечение, используемое на различных технических устройствах или процессы, связанные с участием программного обеспечения. Это важное уточнение, так как в мире существует и другие профессии бизнес-аналитика, которые не связанны напрямую с миром информационных технологий (Например, бизнес-аналитик по процессам организации). В этой книге мы обсуждаем именно ИТ БА – чтобы это было очень явно понятно я даже вставил «ИТ БА» словосочетание в название книги.

Первая история о трудоустройстве в ИТ компанию без ИТ опыта.

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

После этого я просмотрел список наиболее востребованных вакансий на сайтах о работе. Мое внимание привлекли вакансии, связанные с растущим спросом на ИТ специалистов. Я видел множество разных ИТ позиций, но наиболее понятная мне была позиция бизнес-аналитика. Я отправил своё резюме в несколько ИТ компаний и мне естественно везде пришли отказы, так как у меня не было ИТ опыта. Время шло и в один прекрасный день я встречаюсь со своим братом и делюсь своими мыслями про ИТ мир, в который всё-таки видимо закрыты для меня двери. И вдруг, он сообщает, что его друг по школе сейчас по чистой случайности (вот это совпадение!)работает бизнес-аналитиком в ИТ компании и что он с ним поговорит. Признаюсь честно, в целом, я всё равно настроен не очень позитивно, так как мне везде отказывают в ИТ компаниях, даже если я согласен на любую позицию стажера. Через несколько дней брат звонит и сообщает, что договорился со своим школьным товарищем, что-тот посмотрит моё резюме. И подбадривает меня “У нас всё получится – можно устроиться в любую компанию, если настроится на успех типа “я хочу, я смогу!”

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

Первый вариант – ты что-то сделаешь и: а) у тебя не получится и б) у тебя получится.

Второй вариант – ты ничего не сделаешь и это вариант, по сути, равен варианту “б” из первого варианта. Из чего следует простое логическое заключение, что второй вариант бессмысленно выбирать, если он уже включен в первый вариант. Вот я и двигаюсь по первому варианту – всегда попробую и смотрю результат, делаю выводы и пробую дальше.

Я отсылаю резюме и жду ответа. Через некоторое время мы созваниваемся, и друг брата сообщает, что есть два главных замечания по резюме – первое это то, что в моем резюме отсутствует какое-либо упоминание факторов, по которым мной вообще могут хоть как-то заинтересоваться в ИТ компании. Должен быть какой-то якорь – что-то, что зацепит человека, который смотрит резюме в плане навыков. Пусть не вся информации из резюме, но хотя бы ее небольшой кусочек. Чтобы появилась пусть небольшая, но причина (возможно) пообщаться представителю компании с кандидатом. Это может быть его личный опыт в формате “я в свободное время пишу программы” или например, опыт в каком-то бизнес домене как Например, “я детально знаю какие бизнес-процессы существуют в компаниях”. И второе замечание – это то, что резюме – это “лицо” кандидата – когда ты отсылаешь резюме в любую компанию, то твоё резюме является абсолютно первым контактом с компанией. И соответственно первым впечатлением о тебе. Соответственно, моя первая версия резюме не выглядела как привлекательное “лицо”.

Вот всю неделю я и занимался обновлением резюме и перебором пунктов резюме, которые показали бы мою полезность для ИТ компании. Я присылаю резюме еще раз, и он говорит, что теперь “резюме можно уже показывать коллегам в компании” и что поговорит со своим руководителем, чтобы организовать собеседование со мной. Прошла неделя мне назначили собеседование через неделю с руководителем отдела ИТ Бизнес-аналитиков в моем городе. Вот это новость!

Итак, мне нужно подготовиться к собеседованию и разобраться: что за компания куда я трудоустраиваюсь, чем она занимается, чем я буду заниматься если меня возьмут на роль Бизнес-аналитика и как я смогу применить свои текущие навыки/опыт. До собеседования я готовлюсь и изучаю компанию и специфику моей будущей и пока только еще возможной работы. Даже если у меня нет практического опыта в этой профессии, то все равно я должен понимать, что, как и зачем делает ИТ бизнес-аналитик. На любом собеседовании тот, кто проводит собеседование, постарается проверить практический опыт кандидата, а если его нет или он не соответствует требуемому уровню, то этот человек всегда проверит знания и понимании навыка через практические вопросы с воображаемыми сценариями. И вот тут пригодится понимание границ ответственности в должности, на которую я иду и что за обязанности у меня будут – только в этом случае я смогу понять задачу и хотя бы попытаться на нее правильно ответить.

Неделя проходит в подготовке и ожидании дня собеседования. И кстати, часть этой подготовки занимает постоянная и само-утверждающая интенсивная бомбардировка сознания мыслями, создающими по крайней мере личную убежденность, что моё трудоустройство обречено на успех. Обречено на успех, потому что: я именно тот кто нужен этой компании сейчас; я именно тот кто знает бизнес процессы, которые помогут в создании ИТ продуктов; я готов пройти собеседование так, чтобы показать себя в максимально полезном свете; я готов ответить на любые вопросы и практические задачи, которые мне могут задать на собеседовании. Я подготавливаю себя психологически что «всё пройдет успешно!» так как для того, чтобы «победить», у меня должно быть внутреннее правильно состояние как «я уже победил» ну или «я иду оформляться на новую работу (как будто собеседование уже прошло). Не должно быть не одной мысли в ячейке мозга с названием «собеседование» в формате «попробую может повезет» или «начну рассказывать, а там как пойдет» или «ну если не пройду то поищу еще вакансии» или «это не конец жизни не пройти это собеседование» или что-то похожее. Да – естественно мы понимаем, что при прохождении собеседование основной акцент или вес занимает оценка профессиональных навыков, но в дополнение к этому важную роль играет стержень успеха «я тот кто нужен», который скажем так должен исходить от кандидата психологически – в формате его разговора, тона голоса, языка тела, степени уверенности (сейчас это уже стандартный процесс и с онлайн именно видео собеседование в наш постковид время!). Довольно часто из моего опыта именно «я тот, кто нужен» факторы добавляли дополнительный плюс кандидату при собеседовании, которое проводил я. И этот плюс влиял на создание общей картины о результатах собеседования.

Ну вот и наступил март 2013 года и день собеседования. Погода просто отличная – на улице еще прохладно, но в солнечный день уже чувствуется наступление весны, когда греет солнце, и какая-то теплая свежесть ощущается в воздухе и легкость настроения. Но только не для меня именно в этот день. Уже с самого утра у меня включен «режим опасности» в организме. Очень полезный, но нервно-истощающий режим для мозга, который активируется у любого существа на планете, я думаю, когда он чувствует опасность и все рецепторы восприятия обостряются и нервные окончания становятся очень чувствительными – это состояние не связано со страхом неудачи. Так как жизнь большинства людей не связана с реальной угрозой для жизни в своей повседневной жизни, то у людей это психологическое состояние возникает часто по другим причинам, которые влияют на нормальный ход жизни и ценности жизни. Мой пример: если я знаю, что трудоустройство на работу напрямую влияет на благополучие моей семьи, то естественно для меня это ведет к активации состояния опасности. Мысли постоянно крутятся в голове только о предстоящем собеседовании, ладони потеют, во всем теле внутреннее напряжение, небольшая нервозность. Я сконцентрирован только на собеседовании, которое будет через 2–3 часа.

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

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

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

Более серьёзные мысли у меня были о рисках. Для любого человека (и тем более семейного) вопрос уровня зарплаты является приоритетным, при трудоустройстве после определенного времени без работы. Зарплату мне предложили на 40% меньше, чем я получал последние 2–3 года. С одной стороны новая область очень интересует, но есть и обратная сторона медали – это вопрос самому себе «а пойдет ли у меня это направление и насколько успешно?»– ведь я никогда не работал в этом домене и даже приблизительно не могу оценить свой потенциал. И понравится ли мне этот вид активности?

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

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

На следующей неделе я выхожу на свою абсолютно новую работу. Это очень волнующе, так как я не знаю абсолютно ничего о моем новом рабочем месте и обязанностях в деталях. Вот и мой первый день в моей первой ИТ компании. Я одеваюсь, как всегда, в мои первые дни в любых компаниях – рубашка, брюки и туфли (хорошо хоть галстук не одел). Я ненадолго захожу в HR отдел и получаю информацию, где будет мое рабочее место и на каком этаже. Руководитель команды аналитиков сидит на том же этаже, что и я поэтому я сначала подхожу к нему поздороваться и заодно он мне показывает, где я буду сидеть. Обстановка рабочего пространства мне нравится – это так называемое “открытое пространство” (open space). Весь этаж без стен, кроме комнат для совещаний. Несколько рядов столов, где работают коллеги. Руководитель кратко меня представляет коллективу – на моём этаже работает большинство бизнес-аналитиков. Что мне не привычно это то, что все одеты кто как хочет – кто в джинсах, кто в майке, а кто вообще в шортах. В следующие дни я быстро привыкаю к этому свободному формату одежды (дресс коду), способствующему комфортной работе, которая в основном связана с персональным компьютером (по крайней мере в офисе). Что мне очень нравится в мои первые дни это то, что у меня сразу же появляются реальные задачи. И в эти дни я сразу же погружаюсь в удаленный/распределенный формат работы. А происходит это потому, что компонент ИТ системы «Системы по поддержке бизнеса», участвовать в котором и взяли меня на работу, не имеет проектной команды в офисе в моем городе. Поэтому мне определяют проектного ведущего БА и одновременно моего наставника (ментора) из другого города. И последующие 2 или 3 года я работаю со своим ментором полностью удаленно – не разу не увидев его вживую. С первого знакомства я интуитивно чувствую, что мне попался очень хороший ментор в прямом смысле этого слова – тот человек, который может помочь и существенно ускорить усвоение необходимых БА навыков и специфики работы на проекте. Никакой теории – он сначала мне показывает, чем он занимается сам: анализирует бизнес требования, потом создает функциональные требования, общается с коллегами по проекту, общается с клиентом, чтобы прояснять детали о требованиях к системе. Он кратко описывает свои обязанности, но, естественно, я эти активности делать не буду. Мне он сначала дает очень примитивные/простые задачи, но именно те, которые должны поставить меня на “рабочие рельсы”. И на этих простых задачах я следующие несколько месяцев оттачиваю одни из ключевых навыков любого бизнес-аналитика, такие, как анализ и документирование функциональных требований для системы, последовательность, структурированность и логичность написания, простота и понятность написания, эффективное переиспользование форматов/шаблонов и частей уже существующих требований. И я очень четко понимаю, что это обязательная база и я рад, что мой ментор мне не дает никаких более сложных и разнообразных задач. В этом просто нет смысла, так как любая профессия всегда имеет градации уровня владения профессиональными навыками. И главное в любой профессии, это идти поэтапно к повышению своей квалификации и обязанностями. А теперь взгляд немного в другой плоскости на тему трудоустройства БА в ИТ компанию – меняем моё лирическое жизнеописание на более практическое повествование. Добавлю мои рекомендации и полученные уроки (lessons learnt) в условиях текущей реальности.

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

Оба варианта очень похожи с процессной и подготовительной точки зрения. Что бы я выделил:

1.      Мысле-построение, как база при создании настроения и принятия решений.

2.      Планирование начала своего карьерного пути, включая план по трудоустройству.

3.      Подготовка резюме, подготовка и прохождение собеседования.

Итак, про личный настрой (психологическая подготовка) и принятие решений:

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

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

Я занялся своей попыткой трудоустройства как БА именно с внутренней целью-мыслью. И я не говорю, что действия всегда могут привести к желаемому результату, нет. Я вполне предположу, что мои попытки могли бы закончиться негативно с финальным отказом – но я бы в любом случае дошел бы «до конца», сделал бы всё что мог.

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

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

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

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

Для компании важно чтобы человек понимал специфику доменов по проектам и продуктам, с которыми ему нужно будет работать. И компания смотрит, какой практический опыт у кандидата имеется. Довольно часто в моей практике были случаи, когда при найме кандидата в компанию или на проект практическое знание бизнес домена играло ключевую роль. И кстати этот критерий был основным при приеме меня на работу в мою первую ИТ компанию – с одной стороны у меня были нулевые знания в ИТ домене, но с другой стороны у меня был опыт около 6 лет работы в различных компаниях по продаже инженерных продуктов. Я знал детально с практической точки зрения от начала до конца цикл продажи продукта и управления им и работы с клиентами в соответствующих ИТ системах. Интересный момент, что у меня так же был нулевой опыт работы в бизнес домене, к которому относилась компания куда я трудоустраивался – телекоммуникации. Но у меня был отличный практический опыт в операционном домене, который я мог использовать для создания системы по поддержке бизнес-процессов независимо от бизнес домена.

Подумайте в каком домене вы сильны? Сколько лет опыта у вас есть работы в этом домене?

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

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

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

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

3) коммуникация с командой – умение общаться с командой в процессе создания продукта/проекта.

В зависимости от одного из этих уровней работодатель может определить, насколько вы подходите для открытой позиции. В моем практическом примере, когда я трудоустраивался в свою первую ИТ компанию, моего владения английским языком хватало только на первый уровень для написания документации. Но этого было вполне достаточно, так как я трудоустраивался в продуктовую компанию, где серьезный акцент был на разработке собственных продуктов и у многих БА коммуникация с клиентом вообще не входила в обязанности. Я думаю, в данный момент, у многих изучение английского языка начинается возможно еще даже с первого класса школы и довести уровень до одного из трех уровней не должно быть сложной задачей. Так же сейчас есть тысячи бесплатных курсов, программ, книг для изучения. И чтобы повысить свою привлекательность для работодателя, можно запланировать, мне кажется, в течение 2-3 месяцев достичь 1 или даже 2 уровня, а за 6-8 месяцев 3 уровня – т.е. свободного базового владения разговорным английском языком для коммуникаций. Этот критерий хорош тем, что нет никаких препятствий для его развития – всё полностью зависит от вас.

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

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

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

А) трудоустроится за 1-2 месяца: такое трудоустройство по моей оценке возможно при следующих критериях:

1. У вас есть хороший опыт в БА профессии (простой сценарий, что вы решили сменить место работы) или

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

Б) за 3-6 месяцев:

1. Ваш БА опыт не достаточен/зрелый для трудоустройства в новую более зрелую компанию и этого времени хватит для изучения лучших БА практик.

2. У вас есть отличный доменный опыт и нужно прокачать английский и теоретические знания в БА.

С) за 12 месяцев: я добавил такой длительный срок на подготовку для специфичного сценария, но на мой взгляд важного, как для человека с БА базовым опытом, так и без БА опыта:

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

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

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

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

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

Типы компаний для трудоустройства

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

Первый тип – это ИТ компания поставщик сервисов/услуг.

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

Какие позитивные перспективы я бы выделил в таком типе ИТ компаний:

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

наличие большого штата сотрудников в БА домене. Да это критерий, потому что расти можно только в среде, где есть люди с более высокой экспертизой, чем ты. И эти люди будут работать с тобой на одном проекте и делиться с тобой своей экспертизой. Эти люди будут вместе с тобой участвовать в различных внутренних программах и являться тренерами/менторами в обучающих программах. Один вариант как пример – вы устраиваетесь в банк, где на весь банк, например, есть 5-10 БА и большинство из них знает не больше чем вы. Или… вы устраиваетесь в компанию, где работает 1000+ бизнес-аналитиков. Где выше шанс получить развитие вашей экспертизы?

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

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

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

Давайте я теперь коснусь нюансов, что нужно учесть не как негативный фактор, а именно как нюанс – т/е определенное отличие от других типов ИТ компаний (которые мы рассмотрим ниже). Эти нюансы нужно именно учесть, принять их и потом воспринимать соответствующе, когда они возникнут после трудоустройства.

Первый это вероятность отсутствия возможностей для развития в вашем бизнес/операционном домене. Это именно вероятность того, что не всегда ваш глубокий доменный опыт (если он есть) найдет применение в работе и вы его сможете развить. Для некоторых людей это может важно, а для кого-то не критично. Я устроился в ИТ сервисную компанию и никогда больше не работал в домене, в котором имел опыт(телеком) до этого и для меня это не было важно. Так происходит, так как сервисная компания предоставляет услуги разным клиентам для разных проектов. Так же в компаниях могут быть определенные ключевые/популярные домены и если у вас опыт в таком домене, то возможно этот нюанс и не «всплывет».

Следующий нюанс – это высокая динамика смены контекста по проектам/продуктам. Что это? – формат работы сервисных компаний в большинстве случаев подразумевает, что клиенты нанимают их только на определённый проект и на определённый срок. Например, на 6,9,12 месяцев и потом клиент может продлить контракт, а может и нет. И соответственно, все люди, которые работали на проекте, будут перераспределены на другой проект. И этот проект может быть абсолютно другого домена, методологии, и контекста. В отличие от продуктовых компаний (будут описаны ниже) в сервисных компаниях вы можете только-только вникнуть и разобраться в сложном продукте клиента, как проект уже закончился. Это можно рассматривать как негативный фактор, а можно и как позитивный. С одной стороны, вы не успеваете приобрести достаточно экспертизы в конкретном продукте/методологии/домене, при частой смене проектов. С другой стороны, этот нюанс может быть и позитивным фактором, так как вы никогда не заскучаете на проекте, продукте, области работы. И всегда есть возможность постоянно изучать новые проекты продукты и получать новые опыт и навыки. Вот такой вот нюанс! Если спросить меня, то для меня это позитивный нюанс по обозначенным выше критериям. Плюс я бы, наверное, добавил еще один пункт – работа БА имеет свою специфику в контексте длительности проектов/продуктов. Проект должен быть очень и очень большим (по всем критериям), чтобы БА на нем был на 100 процентов загружен постоянно новыми и интересными задачами после работы, например, один год на проекте. Для меня смена проекта на новый через… Например, 12 месяцев является очень и очень позитивным рабочим изменением и свежей струей воздуха в работе, которая не дает истираться.

И последний нюанс, который вначале может показаться вроде, как и напрямую не касается именно проектных и БА активностей, но нюанс все же есть. В сервисной компании есть разные ценовые и контрактные модели взаимоотношений с клиентом. Вот основные два разреза:

1. Формат найма – клиент нанимает в сервисной компании: а) целостную проектную команду, которая должна поставить какой-либо продукт; б) целостную проектную команда, которая должна помочь создавать проект вместе с командой клиента в) просто рабочие ресурсы для своих разнообразных задач.

2.Тип ценовой модели и контракта: а) фиксированная цена – когда клиент хочет определенное решение и чаще всего к определенному сроку и готов заплатить определенные деньги; б) время и материалы – когда клиент готов платить на постоянной основе за определенные объемы выполненной работы. Единицы измерения могут быть, например, «кол-во людей в месяц» или «кол-во задач выполненных в месяц» (или в квартал, в полгода)

Оба разреза могут пересекаться в разных комбинациях. Я думаю, что проще всего смогу объяснить, в чем здесь нюанс для БА на паре примеров. Например, вы попали на проект, где контракт имеет тип “время и материалы” (time & materials) и клиент просто попросил предоставить ему 20 человек для своих нужд. На таком проекте вы работаете как часть команды клиента и получаете разнообразные задачи от представителей клиента и вполне возможно будете иметь довольно низкий уровень влияния на принятие каких-либо решений и даже связанных непосредственно с вашими БА активностями. Пришел кто-то и попросил сделать что-то и зачем-то – нужно сделать. Другой пример – вы подключились на проект по фиксированной цене и срокам, и ваша команда состоит полностью из коллег из сервисной компании. Например, через 12 месяцев нужно сделать продукт и выдать его клиенту. Тут будут проявляться высокий уровень ответственности и часто отсутствие какой-либо гибкости в подготовке конечного решения. Так как, когда такой контракт заключен, то обычно уже обсуждены все границы и объем решения, за которое определена фиксированная цена.

Второй тип компаний – компания поставщик ИТ продуктов. Это компания, которая разрабатывает свой ИТ продукт, который поставляет другим бизнес-клиентам. Например, моя первая ИТ компания была как раз такой компанией поставщиком ИТ продукта в телекоммуникационном домене. Есть интернет-провайдеры, которым нужны ИТ продукты/программы, которые помогут им управлять и увеличивать эффективность и продуктивность своих бизнес-процессов. Например, каталог хранения продуктов нужен абсолютно любому Телеком оператору, который предлагает услуги интернет, мобильной связи, тв. Такой компании не нужна услуги ИТ сервисной компании. Им нужен конкретный продукт, который будет им поставлен и модернизирован/кастомизирован под их нужды и требования. Какие позитивные критерии я озвучил бы о таких компаниях?

В первую очередь это возможности получения глубокого доменного и продуктового опыта. Это прямо противоположное преимущество сравнивая с сервисными ИТ компаниями. Опять же всё зависит от желания и планов конкретного человека, как я говорил – поэтому я и описываю это. Представьте вы, приходите в продуктовую компанию, которая последние 10-15-20 лет разрабатывает один продукт (или линейку продуктов) в конкретном бизнес домене. Вы включаетесь в разработку продукта и предоставление этого продукт для клиентов. У вас есть отличный шанс получить глубокие доменные знания и так же домен специфик подходы к созданию и поставке решений для доменных клиентов. С течением времени вы станете экспертом в данной области/домене.

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

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

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

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

Из нюансов я бы подсветил тот же пункт с плавающей динамикой экспертизы в БА области – иногда на весь ИТ департамент может быть всего 3-5 БА и вы один из них и соответственно, не о каком развитии БА экспертизы не идет речь. Еще я бы, наверное, добавил второй нюанс, что есть вероятность, что ИТ департамент будет выполнять, то что «спускают сверху» вниз руководители других бизнес департаментов и соответственно гибкость в создании или изменении чего-либо будет минимальна («бюджет утвердили – задачу сказали – делай и не задавай вопросов»).

Ну вот собственно и все про типы компаний – если есть и еще какие-либо виды, то в большинстве случаев это гибриды из этих трех.

И уточню еще раз мои формулировки и пояснения про “нюансы” – это только нюансы и не в коем случае не негативные пункты. Так же мы понимаем, что абсолютно каждый человек индивидуален в своих рабочих/профессиональных стремлениях и то, что для одного может быть нюансом, для другого может быть перспективой.

Выбирайте формат своей компании на основании ваших целей/стремлений – хотите ли стать экспертом в БА области или в определенной продуктовой/доменной области. Любите ли вы частую смену вида деятельности или вам без разницы.

Мы обсудили какие есть работодатели, подумали над своими сильными и слабыми сторонами и определили примерную временную линию (timeline) сколько мы хотим потратить на достижение своей цели.

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

Подготовка резюме

Этот пункт я описываю исключительно с практической точки зрения, с учетом моего опыта как менеджера по проведению БА собеседования для приема на работу. Я просмотрел резюме и прособеседовал множество кандидатов за последние 5 лет и на мой взгляд, по факту есть немного пунктов, которые нужно учесть. Некоторые из них, возможно, могут показаться очевидными, но я видел достаточно резюме и собеседований, где эти пункты были упущены кандидатами.

Составление резюме:

Хорошо составленное резюме понадобится для самого первого шага при поиске работы – этот тот документ/артефакт, который отправляется потенциальному работодателю. Резюме это первое впечатление работодателя о вас. И у работодателя может быть несколько отделов, которые это резюме будут просматривать. Например, естественно, сначала будут смотреть сотрудники HR отдела и для них важно из резюме увидеть основные факты, которые укажут на то, что ваша кандидатура частично или полностью соответствует тем требованиям, которые у них указаны для открытой вакансии. Только после нахождения таких фактов обычно HR сотрудники передают CV/резюме дальше. Небольшой пример о моем опыте отправки резюме без фактов о ИТ опыте – не один HR сотрудник ИТ компании не заинтересовался моим резюме, когда я в самом начале разослал моё обычное не ИТ резюме в несколько ИТ компаний города.

Думаю, в интернете есть тысячи статей про составление резюме, поэтому здесь я только кратко коснусь некоторых полезных аспектов/рекомендаций и приведу примеры трансформации моих реальных резюме. Я не говорю, что они идеальны, но это форматы, которые я использовал.

Про аспекты – я хочу выделить следующие:

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

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

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

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

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

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

Это самое первое резюме, когда я первый раз устраивался в свою первую ИТ компанию (то что я описывал несколько страниц назад) – в нем я допустил ошибки по всем аспектам выше. Был позитивный момент в том, что знакомый, который мне помогал трудоустроиться, подсказал поправить резюме по первому аспекту в плане соответствия информации должности. Хоть у меня и не было опыта в ИТ домене, но я указал те пункты, которые имели значение на той позиции, куда я пытался трудоустроиться. Вот пример ниже, где я даже добавил целый раздел “ИТ навыки” (IT Skills), а также указал хоть и не ИТ навыки, но существенно применимые к БА должности, такие, как Аналитические навыки, опыт взаимодействия с клиентами и знание СRM/ERP систем:

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

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

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

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

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

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

Прохождение собеседования

После того как резюме готово и отправлено, можно начинать готовиться к прохождению собеседования. Какие рекомендации я могу дать при подготовке к собеседованию? Думаю, довольно стандартные. Первая – нужно изучить описание вакансии и обязанностей, чтобы быть: готовым спросить то, что непонятно; примерить заранее свой опыт на ожидания работодателя; заранее решить, как себя вести/отвечать при наличии пробелов в опыте/навыках. Вторая это изучить информацию о компании – чем занимается, какие продукты и так далее.

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

Забыл указать еще один важный момент – всегда и всегда воспринимайте собеседование и настраивайте психологически себя перед собеседованием, что собеседование – это равноправный диалог между двумя сторонами – это не вы устраиваетесь/ищете работу и не работодатель рассматривает вас “под лупой” и не вы продаете себя как суперэксперта. А просто два (или больше) человека встретились, чтобы обсудить взаимовыгодное сотрудничество. Мне именно такой психологический настрой очень нравится. В моем голове он выглядит как внутренняя мысль/настрой «всем привет! Давайте обсудим в чем мы можем посотрудничать!» Естественно, не стоит это говорить, как только придёте на собеседование. И еще при таком настрое вы сможете определить, насколько это открытая и подходящая вам компании. Вроде всё обсудили и надеюсь, что мои практические советы будут полезны!

Советы, если меняем место работы…

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

Большие деньги (ну конечно куда без них) Перед тем как поселить в голове у себя мысль «охххх от такой зарплаты я не могу отказаться!» проверьте/учтите следующие пункты:

1. Насколько большая зарплата? – если это разница до 30-40 процентов то:

а) возможно, вам смогут сделать аналогичное увеличение и внутри текущей компании. Да, не сразу, но с договоренностью увеличения в течение определенного времени.

б) оцените, насколько следующие критерии ниже лучше, чем в вашей текущей компании.

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

2. Если вы смотрите предложения из других городов/стран – обязательно изучите два критерия а) уровень жизни в целевом городе – сейчас множество вебсайтов, где можно посмотреть средний уровень расходов и сравнить между собой города (питание, аренда и так далее). И главную роль естественно будут играть затраты на аренду жилья б) налоговые законы. Во многих стран зарплату предлагают ГРОСС – то есть с учетом налогов и измеряется сумма денег в год. Зарплата может выглядеть большой, но поделите на 12 месяцев и вычтите размер (он может быть и 30 и 40 и 50%) налога и тогда проверьте хватит ли вам и вашей семье этого. Важно не ошибиться в изучении налоговой ставки, так как почти всегда это обязанность именно сотрудника и компания, естественно, никак не связана с вопросами налогообложения. Бывают и такие подводные камни, например, как прогрессивный налог, зависящий от уровня зарплаты – Например, вы быстро проверяете в интернете ставку на зарплату и первые запросы пишут 24-29 процентов. Вы думаете – всё ок. Но если копнуть глубже и найти сайт с сеткой зарплат-налогов, то с уровнем вашей зарплаты налог будет уже 48 процентов, и ваша ежемесячная чистая зарплата будет уже совсем другая.

3.Условия предложения/оффера – не стесняйтесь уточнить, есть ли какие-либо обязательства по денежным суммам, указанным в предложении. Например: в предложении указано 75 000 евро и 5000 евро бонус при трудоустройстве. После уточнения появляются детали, что 75 000 это 60 000 + 15000 как годовой бонус с оценкой производительности. А бонус выплачивается после вычета 30 процентов налогов (т.е. это примерно 3500 евро) и плюс сотрудник не имеет право уволится в течение года, иначе будет обязан вернуть бонус. Это не негативные условия, а просто условия, на которые нужно обратить внимание и учесть.

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

Контекст и Стабильность компании (не получится ли что завтра меня попросят уйти?) – я сталкивался с ситуацией, когда коллега планировал уйти в другую компанию, но после нашего совместного анализа этой компании, передумывал только из-за этого критерия. А) Посмотрите на размер компании. Например, если вся компания это 100-200 человек или меньше то лучше подумать. Б) Проверьте отзывы на сайтах о работодателях. Не стесняйтесь спросить такие вопросы как «а сколько у вас всего БА в компании?» или «сколько у вас сейчас активных проектов и средняя численность команд на проектах?». Если Например, всего в компании сейчас всего 5-10 БА, а вы еще только начинаете свой БА путь, то вы должны понимать, что вероятность получить достаточно экспертизы и расти в такой компании будет не велика (хотя это уже следующий пункт ниже, но все же это контекст компании)

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

Вот и все рекомендации для этой истории и надеюсь они пригодятся, особенно если вы хотите сменить место работы и хотите найти нового надежного работодателя на ближайшие 5-10 лет.

Я никак не закончу эту вступительную главу – прошу извинить меня, так как читатель наверняка уже скорее хочет почитать про то, чем же всё-таки занимается БА в начале своего карьерного пути! Но я позволю себе сделать еще одну маленькую вставку перед концом истории, про самый главный вопрос самому себе на мой взгляд – «А зачем мне вообще именно работа БА в моей жизни?». Смотря на свой опыт работы БА в течение последних 10 лет, я хочу упомянуть очень простые мотиваторы или причины почему мне нравится эта профессия каждый день/неделю/месяц/год. Я вижу всегда два вида мотиваторов – внутренние и внешние.

Зачем становиться БА

Внутренние – зачем это мне?

Идеальная пропорция Деньги-Рабочая нагрузка-Моя жизнь (Work-Money-Life Balance) – я работал всего в двух ИТ компаниях за последние 10 лет и смотря на эти 10 лет и эти компании (Неткрекер и ЕПАМ) для меня – это фантастическое персональное удобство работать Бизнес-аналитиком. Уровень оплаты в сравнении с рабочей нагрузкой и временем на личную жизнь – он идеален. Если назвать баланс Работа/Жизнь/Деньги параметром, то я бы поставил ему значение в 90 процентов по уровню удовлетворенности (и 10 процентов оставить для дальнейших улучшений). Я планирую свой рабочий день, неделю как мне удобно. Я могу один день работать 7 часов в день, а другой день только 4 часа в день, если я хочу или если имею личные важные дела ( и не очень). Я могу работать из дома, из кафе, из другого города, с пляжа – мне нужен только мой ноутбук. Я знаю, что сейчас многие компании после ковида переходят на удаленный формат работы и так же не имеют фиксированных часов работы, но тут я хочу уточнить, что я говорю именно про работу как БА. Именно в этой работе на мой взгляд существует “дух свободы”. Приземленное уточнение – естественно всё это возможно, если вы выполняете все задачи в установленные сроки и с соответствующим качеством.

Мировой опыт – мне очень и очень завлекает и вдохновляет работа (конечно, это специфика моей текущей компании, но…) в международной компании крупной компании и на международных проектах. Это постоянное получение новых знаний, информации, опыта, навыков из разных источников. Масштаб проектов/продуктов позволяет получать международный опыт и личное понимание что «Да! То, что я создаю, я создаю с использованием процессов и подходов, как это делается по всем миру разными компаниями/проектами/командами!»

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

Внешние – как мир влияет на мою мотивацию?

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

Увеличение масштабов решений и требований к качеству решений – с развитием ИТ технологий («облачные» решения, машинное обучение, «Большая» дата и аналитика – только некоторые из них) растут масштабы ИТ решений у клиентов и соответственно… процент возникновения дефектов. Одним из ключевых участников проектной ИТ команды по поставке решений, который влияет на качество решения, является БА. Это очень заметный мотиватор, по крайней мере в сервисной компании, где работаю я – когда я вижу проекты на 4-7 команд (20-40 человек), где набирают по 4-5 БА. Клиенты и поставщики решений понимают, что должен быть БА почти на каждую даже небольшую команду, который полностью бы готовил требования и управлял их жизненным циклом для каждой части решения для каждой команды.

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

Да и просто цифры (которые я взял из Линкедин):

Рассмотрим спрос на профессии. Я не буду брать актуальную статистику текущего года, так читатель и сам может это сделать. Но, например, я возьму статистику далекого 2019 года и уже там виден прекрасный спрос на профессию Бизнес-аналитика.

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

Software engineer – Инженер-программист

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

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

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

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

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

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

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

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

2020 году

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почемучка

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

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

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

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

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

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

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

Шаг, в котором я продолжаю работать с требованиями, обращаю уже больше внимания на некоторые области управления требованиями, стараюсь забрать больше ответственности и самостоятельности для полноценного документирования функций системы и всё это уже не под таким пристальным вниманием своего ментора/ведущего БА.

Через пару месяцев мой проектный БА оценил развитие моих навыков и способности и уже стал мне передавать на документирование требования и дизайн к целым функциям компонента системы. Это меня конечно же несказанно радовало, что и говорить! Это приятное ощущение, которое я описывал выше, когда ты всё лучше и чётче понимаешь, что ты именно создаешь что-то от начала до конца. Что же именно такое функция? Возьму тот же пример из предыдущего первого шага – у нас есть компонент системы, который называется “система управления информацией о клиентах”. Внутри этого компонента есть различные функции – создание профиля клиента, редактирование профиля клиента, просмотр и управление кредитной информацией о клиенте и много других. Внутри каждую функцию можно декомпозировать на множество подфункций или требований (2,3….И так далее). Одно из таких требований для функции про кредитную информацию мы и разбирали на предыдущем шаге. Соответственно функция – это определенный набор свойств и действий (как пользователя, так и системы), которые предоставляют конечному пользователю выполнить полноценное и завершенное действие с определенным ожидаемым результатом. Как я упомянул, например, функция «создать профиль клиента».

Я начал получать задачи по подготовке функций. Вариаций типов задач, активностей и ответственности стало больше – что отражало продолжение моего профессионального роста. Я чувствовал, что уровень сложности поднимается – теперь задача была не просто написать требование и задокументировать его. Теперь мне нужно было проанализировать требуемую функцию, декомпозировать, определить и задокументировать необходимые требования и дизайн, правильно связать все требования вниз и вверх в матрице требований, управлять статусом готовности и блокерами, и подготовить вопросы для стейкхолдеров(Stakeholders) на стороне клиента. Да, да! – “толпа” всего нового. И как следствие – в дополнение появились еще не только задачи связанные с функциями, но и общие профессиональные задачи, как следствие возросшей сложности: валидация и обслуживание (и изменение если нужно) информационной модели/структуры требований и дизайна и поддержание логичности; понимание работы модели данных; понимание формата работы с представителями клиента; создание спецификаций модели данных; понимание жизненного цикла разработки системы; и конечно же развитие дополнительных и необходимых «мягких» навыков. Столько всего…наверное сразу «раскрыл карты» о навыках и активностях, которые дальше буду описывать, но так вот – никаких секретов! Единственное я вижу упомянул новое слово «стейкхолдер» – поясню его и продолжим. Стейкхолдер это человек, который ожидает и будет иметь какую-либо выгоду и/или будет пользоваться ИТ продуктом, который я создаю. Для проектов компаний поставщиков сервисов или продуктов, которых нанимают другие компании – основные стейкхолдеры это всегда люди на стороне клиента, те кто ожидают готовый продукт. Это может быть всего один человек, который взаимодействует с сервисной компанией или множество людей на стороне клиента. Это люди разных уровней организации клиента – генеральный директор, его заместитель ИТ департамента, экономический отдел или отдельная проектная команда, которая курирует создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. И у них БА выявляет требования к системе/продукту. Позже мы детально рассмотрим БА навык “управление стейкхолдерами”.

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

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

На звонке мы определили, какие вопросы БА прояснит с клиентами, так как Например, были неясности в бизнес-требованиях, которые по своей природе и не должны быть подробно-детальными. Так же я получил ценное замечание, о котором совершенно не подумал – о интеграции моей функции с существующей в нашем продукте общей системой управления адресами. Так как адреса используются в множестве модулей/компонентов, то у нас и отдельный компонент был для этих целей. Мы обсудили, что нужен будет интеграционный маппинг (mapping – маппинг. В данном контексте это модель соответствия данных между разными интегрируемыми системами), а также мне нужно изучить нашу существующую систему управления адресами. И последним пунктом мы обсудили первые требования из декомпозированных, которые наиболее понятны и которые уже можно было бы начать документировать. Как итог звонка появились задачи для каждого, которые нужно выполнить и в определенный срок. БА попросил меня прислать итоги нашего звонка так же в письме. Как всегда, любое обсуждение планируемых задач с коллегой принесло много пользы – это большой плюс работы в команде (пусть даже и маленькой команды). В течение 30 минут я прислал митинг ноутсы (Meeting notes – МН сокращенно – значит записи с митинга) в письме, где включил информацию о том, что мы обсудили и что/кто должен сделать и когда. Я хотел бы сделать акцент на этом фантастически полезном и ценном артефакте «митинг ноутс» – им я пользуюсь все последние 10 работы в ИТ всегда и везде. Почему фантастически? Потому что этот артефакт мне помогал и помогает структурировать планы мои, команды, клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу любых договоренностей (которые указаны в этих записях); определить ответственные стороны/людей и сроки выполнения; и является самым надежным коммуникационным каналом по сохранению информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то потом очень сложно изменить эту информацию. Я лично отправляю МН всегда – даже когда меня никто об этом не просит. Это дает мне 100 процентную уверенность, что всем донесена информация, даже если на самом совещании кто-то был не очень вовлечен по каким-либо причинам – такой человек может потом найти время и прочитать МН позже. И за свою карьеру у меня было множество сценариев, когда МН артефакт спасал от масштабных проблем/споров на разных уровнях менеджмента между клиентами и моей компанией. Так, например, когда вопрос касается денег, а кто-то на стороне клиента упустил важный пункт, который был указан в МН, то на словах человек может в силу своей роли убеждать, что чего-то не было или что-то было неправильно понято. Но пересылка участнику МН письма 6-месячной давности, где он был в получателях и согласился со всем предложенным – решает проблему положительно почти всегда. Я приведу небольшой пример МН которое отослал, чтобы показать именно структуру МН письма – простую и очень эффективную.

Письмо, которое я отправил своему БА:

Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»

Тело письма: «

Обсудили:

Требования к новой функции

Требования, которые можно брать в работу

Требования, которые нужно прояснить с клиентом (номера требований)

Экшн айтем (action items – пункты действий):

Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)

Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.

Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.

Дополнение: допиши если я что-то упустил.»

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

Далее я занялся документированием уже финального варианта функциональных требований, которые были бы готовы к просмотру клиентом. Я определил в какой документ включу блок требований, какой формат нумерации буду использовать. Формат нумерации я уже упоминал ранее и полезность этого уникального номера требования, который в последствии может использоваться при обсуждении с членами команды или клиентом. При просмотре требований он позволяет сделать удобные ссылки на конкретное требование, без указания полностью этого требования. Например, требование имеет номер ФР-СИМ-СИД-02. Клиент при проверке требований может делать пометку «требование ФР-СИМ-СИД-02 не понятно и следует добавить детали». В плане формата требований я старался следовать простому правилу – постараться уместить требование в одно предложение. Т/е/ написать в максимально простой форме. У меня было черновое требование, которое звучало как «Должна быть возможность создавать адрес для клиента, заполнять необходимые поля и редактировать если нужно». Я разбил этот черновик на следующие требования:

«Система должна предоставлять возможность создать адрес для клиента»

«система должна предоставлять возможность редактировать адрес для клиента»

«Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.»

Атомарность требований позволяет потом намного проще решать любые вопросы например, с клиентом, когда появляются вопросы или пожелания к дополнению/изменению требований. Простой пример, с которым я сталкивался – клиент может просмотреть и согласится требованиями №2 и №3, но сказать, что для №1 он хотел бы подтвердить, из каких частей приложения можно будет инициировать создание адреса. И в этом случае возможно потребуется изменение только одного требования в то время, как остальные два уже будут утверждены. Пример естественно относительный и масштабируемый – таких требований у меня было и 50, и 100 и 300 и их простота и самодостаточность позволяла иметь эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а часть как требующих прояснений. После подготовки всех функциональных требований я проверил, что они все имеют связи в матрице отслеживаемости требований – на данный момент я проверял отслеживаемость/наличие связей между бизнес и функциональными требованиями. А именно я проверял, что каждое функциональное требование имеет по крайней мере одно бизнес-требование, которому оно требуется – то есть нет «бесполезных» функциональных требований, на которые будет потрачено время, но которые не нужны клиенту. И так же я проверял с другой стороны, что нет бизнес требований, которые не указывают ни на одно функциональное требование – т.е. что я не упустил ничего, что хочет клиент. После того как все требования были написаны, я отправил их на проверку ведущему БА, который дал немного комментариев. Я сделал правки и в итоге функциональные требования отправили на просмотр и утверждение клиенту.

Утверждение требований

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

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

Пока я ждал утверждения или комментариев от БА по итогам обсуждения списка функциональных требований с клиентом, я сконцентрировался на написании дизайна к требованиям. Дизайн выглядел примерно так же, как я уже описывал в шаге 1, поэтому не буду еще раз описывать, что я делал. Я старался постоянно улучшать качество дизайна. Но вот завершая первый же дизайн я столкнулся с новой интереснейшей задачей.

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

Моделирование требований

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

Почему наличие/создание модели данных важно при подготовке такой вещи как книга или любой системы? На том же примере с книгой я бы построил такую логическую цепочку и всё выглядит довольно прозрачно: 1) цель создания почти любой сущности в нашем мире это ее использование человеком. 2) использование человеком значит использование человеком функций предмета/системы. 3) функции предмета/системы – это как раз функциональность, которую мы так же опишем для системы или для книги. Для книги главная функция это «читать книгу». 4) Но, чтобы читать что-то, нужно иметь этот предмет/систему физически – т/е/ должно быть описание и модель как будет выглядеть книга и из каких объектов будет состоять. 5) Плюс все части книги должны иметь правильные свойства – представьте если из нашего примера мы указываем свойство «вес» для объекта обложки равное 30 кг? – вряд ли такую книгу будет возможно читать! 6) так же все объекты должны быть связаны между собой правильными связями – мы ведь не хотим, чтобы страницы были склеены между собой, а текст был указан только на обложке, а не на листах книги.