скачать книгу бесплатно
Думаю, в интернете есть тысячи статей про составление резюме, поэтому здесь я только кратко коснусь некоторых полезных аспектов/рекомендаций и приведу примеры трансформации моих реальных резюме. Я не говорю, что они идеальны, но это форматы, которые я использовал.
Про аспекты – я хочу выделить следующие:
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 у тебя мне кажется нужно …»).
Шаги/Сценарий:
На странице профиля компании система отображает раздел «кредитная информация».
В разделе «кредитная информация» отображаются следующие поля/данные:
«Кредитный рейтинг» название- текстовое, неизменяемое.
