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

скачать книгу бесплатно


Кредитный рейтинг значение – неизменяемое, цифровое, двузначное, с поддержкой десятичного значения, диапазон значений: от 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) так же все объекты должны быть связаны между собой правильными связями – мы ведь не хотим, чтобы страницы были склеены между собой, а текст был указан только на обложке, а не на листах книги.