Приветосики!
Давайте поговорим о простой и в то же время крайне мощной и полезной технике бизнес-анализа — CRUDL.
Для начала: CRUDL — это техника анализа требований. Звучит красиво, но по факту означает, что это некий прием, позволяющий аналитику осмыслить полученную им информацию с какой-то полезной целью. Все мы знаем (ну или как минимум догадываемся), что одним из ключевых критериев качества требований является полнота. В данном случае мы будем рассматривать полноту применительно к некой совокупности требований, а не их единичному воплощению. Так вот, мы знаем, что полнота требований — это прямо-таки важно, и что пробелы в требованиях ведут к массе негативных последствий. И одним из вариантов анализа полноты вашего набора требований (и, как следствие, помощи в достижении бОльшей полноты) является CRUDL.
Применима ли эта техника для обеспечения полноты требований любого вида? К сожалению, нет. Например, в анализе полноты атрибутов качества системы CRUDL вам ни разу не поможет. Давайте тогда очертим границы применимости, раскрыв параллельно суть подхода. CRUDL — это чеклист типовых операций над чем-то в IT-решении:
Create — создание объекта
Read — просмотр информации об объекте
Update — редактирование/изменение информации об объекте
Delete — удаление объекта
List — просмотр списка объектов (это второстепенная, если сравнивать с предыдущими, операция: практически всегда, когда объектов много, для того, чтобы просмотреть или изменить информацию об конкретном объекте, вначале нужно просмотреть список всех объектов, дабы из него выбрать интересующий)
Чеклисты — вещь вообще крайне полезная в анализе полноты чего-либо. Допустим, вы собираетесь в отпуск — как не забыть взять все необходимое? Иметь список этого самого необходимого aka чеклист. Именно проходя по списку типовых вещей, которые вы берете в отпуск, вы обеспечите полноту вашего процесса сбора. Если вы мегаорганизованный человек, то у вас наверняка есть чеклисты на всё, что вам приходится делать более одного раза — очевидно, что человеческая память в подобных ситуациях пасует.
Спектр применимости техники CRUDL — это операции над объектами в системе. Как правило, это означает помощь в анализе полноты скоупа (границ) системы: любая существенная операция над объектом в системе — это большой кусок функциональности или значимое для пользователя действие, а потому (за счет своей крупности и значимости) это элемент скоупа, важная частичка наполнения решения.
Что это за объекты, по отношению к которым стоит применять CRUDL? Объекты/сущности данных, кои являются частью требований к данным для вашего решения. В одной из статей я рассматривал такую полезную штуку, как логическая модель данных. Соответственно, к крупным частичкам в картине данных решения (т. е. к сущностям, а не к их атрибутам) вам и стоит применять CRUDL.
Давайте рассмотрим алгоритм использования и разберем на примере:
1. Вам нужно научиться вычленять требования к данным в общей массе информации, с которой вы работаете.
Что такое данные? Данные — это информация, затрагиваемая решением. Вместе с процессами (алгоритмами), которые этой информацией оперируют, данные составляют функциональные требования к решению. Давайте не забывать о том, что мы как IT-аналитики работаем в сфере IT-решений: информационные технологии. Любая IT-система оперирует информацией (получает ее на вход, преобразует, отдает пользователям или другим системам — так или иначе, информация фигурировать в вашей системе будет). Соответственно, распознавать блоки этой информации и уметь их систематизировано представить в числе требований — немаловажный навык.
Пример. К вам обратился клиент, горящий стартапом, — разработать онлайн-портал по заказу услуг фитнеса на дом. Допустим, часть исходного описания от клиента звучит так:
Я сам фитнес-тренер, плюс у меня много знакомых, которые будут представлены как тренеры на сайте. Хочу, чтобы для клиентов наш сайт был надежным местом, которое позволит взаимодействовать клиентам и тренерам. Люди должны иметь возможность быстро и удобно найти интересующего тренера, глянуть отзывы о нем и заказать и оплатить услугу с ним.
Давайте проведем базовый словесный анализ и выделим то, какими данными будет оперировать решение. Мы сознательно пропускаем значимые discovery-этапы и активности бизнес-анализа, как-то анализ потребности, проработку бизнес-требований и пр. — все это, несомненно, важно, но не в контексте данной темы. А потому представим, что вы уже совместно с клиентом определились с тем, что и зачем вы будете делать.
То, что нужно рассмотреть как часть будущей картины данных портала, — это подчеркнутые в исходном тексте слова. Тренеры, клиенты — это, судя по описанию, Пользователи решения. Сюда же добавим Услуги — нечто, что Пользователи-тренеры будут предлагать Пользователям-клиентам. Для таких Пользователей, как Тренеры, будут Отзывы. На данном этапе работы с исходным текстом нам этого хватит. Опытный аналитик мог бы погрузиться и глубже — задуматься про механизм оплаты, админскую часть и прочие неявные блоки, которые он, исходя из опыта, уже видит по подобному описанию, но мы-то с вами неопытные и только-только учимся вычленять подобные частички. В общем, нехитрый анализ говорит нам о том, что в целевом портале на уровне данных в системе будут храниться (а если не храниться, то как минимум система будет оперировать ими в том или ином ключе) Пользователи двух видов (Тренеры и Клиенты), Услуги, привязанные к Тренерам, и Отзывы, привязанные к Тренерам и оставляемые Клиентами. Ну и огонь. Первичный анализ сделан.
2. Примените CRUDL ко всем объектам данных, которые вы видите на текущем этапе.
У нас в примере — некий начальный этап: мы ничего не знаем о наполнении системы, не считая краткого пассажа от клиента. Но вообще CRUDL как техника применяется на любом из этапов БА — стартуете вы проект и хотите прояснить его наполнение (скоуп) или обрабатываете CR в режиме поддержки уже работающей системы: всегда, когда появляется какая-либо хотелка, в которой вы можете вычленить кусок данных, вы можете применить к этому CRUDL, дабы убедиться, что как минимум по базовым операциям вы ситуацию с ЗЛ прояснили.
Как применять технику?
В интернете есть много вариаций, которые сводятся тупо к разной структуре таблиц, с помощью которых вы будете оформлять ваш CRUDL-анализ. Но имхо формат таблицы — крайне вторичная штука; на самом деле подобный анализ можно просто делать в голове, не документируя никак его ход. Давайте попробуем один из наиболее простых вариантов:
Определим, что из мнемоники CRUDL было затронуто в исходном тексте. Не обязательно буквально — подумайте, в виде чего в контексте вашего проекта скрывается та или иная базовая операция.
Давайте поговорим о простой и в то же время крайне мощной и полезной технике бизнес-анализа — CRUDL.
Для начала: CRUDL — это техника анализа требований. Звучит красиво, но по факту означает, что это некий прием, позволяющий аналитику осмыслить полученную им информацию с какой-то полезной целью. Все мы знаем (ну или как минимум догадываемся), что одним из ключевых критериев качества требований является полнота. В данном случае мы будем рассматривать полноту применительно к некой совокупности требований, а не их единичному воплощению. Так вот, мы знаем, что полнота требований — это прямо-таки важно, и что пробелы в требованиях ведут к массе негативных последствий. И одним из вариантов анализа полноты вашего набора требований (и, как следствие, помощи в достижении бОльшей полноты) является CRUDL.
Применима ли эта техника для обеспечения полноты требований любого вида? К сожалению, нет. Например, в анализе полноты атрибутов качества системы CRUDL вам ни разу не поможет. Давайте тогда очертим границы применимости, раскрыв параллельно суть подхода. CRUDL — это чеклист типовых операций над чем-то в IT-решении:
Create — создание объекта
Read — просмотр информации об объекте
Update — редактирование/изменение информации об объекте
Delete — удаление объекта
List — просмотр списка объектов (это второстепенная, если сравнивать с предыдущими, операция: практически всегда, когда объектов много, для того, чтобы просмотреть или изменить информацию об конкретном объекте, вначале нужно просмотреть список всех объектов, дабы из него выбрать интересующий)
Чеклисты — вещь вообще крайне полезная в анализе полноты чего-либо. Допустим, вы собираетесь в отпуск — как не забыть взять все необходимое? Иметь список этого самого необходимого aka чеклист. Именно проходя по списку типовых вещей, которые вы берете в отпуск, вы обеспечите полноту вашего процесса сбора. Если вы мегаорганизованный человек, то у вас наверняка есть чеклисты на всё, что вам приходится делать более одного раза — очевидно, что человеческая память в подобных ситуациях пасует.
Спектр применимости техники CRUDL — это операции над объектами в системе. Как правило, это означает помощь в анализе полноты скоупа (границ) системы: любая существенная операция над объектом в системе — это большой кусок функциональности или значимое для пользователя действие, а потому (за счет своей крупности и значимости) это элемент скоупа, важная частичка наполнения решения.
Что это за объекты, по отношению к которым стоит применять CRUDL? Объекты/сущности данных, кои являются частью требований к данным для вашего решения. В одной из статей я рассматривал такую полезную штуку, как логическая модель данных. Соответственно, к крупным частичкам в картине данных решения (т. е. к сущностям, а не к их атрибутам) вам и стоит применять CRUDL.
Давайте рассмотрим алгоритм использования и разберем на примере:
1. Вам нужно научиться вычленять требования к данным в общей массе информации, с которой вы работаете.
Что такое данные? Данные — это информация, затрагиваемая решением. Вместе с процессами (алгоритмами), которые этой информацией оперируют, данные составляют функциональные требования к решению. Давайте не забывать о том, что мы как IT-аналитики работаем в сфере IT-решений: информационные технологии. Любая IT-система оперирует информацией (получает ее на вход, преобразует, отдает пользователям или другим системам — так или иначе, информация фигурировать в вашей системе будет). Соответственно, распознавать блоки этой информации и уметь их систематизировано представить в числе требований — немаловажный навык.
Пример. К вам обратился клиент, горящий стартапом, — разработать онлайн-портал по заказу услуг фитнеса на дом. Допустим, часть исходного описания от клиента звучит так:
Я сам фитнес-тренер, плюс у меня много знакомых, которые будут представлены как тренеры на сайте. Хочу, чтобы для клиентов наш сайт был надежным местом, которое позволит взаимодействовать клиентам и тренерам. Люди должны иметь возможность быстро и удобно найти интересующего тренера, глянуть отзывы о нем и заказать и оплатить услугу с ним.
Давайте проведем базовый словесный анализ и выделим то, какими данными будет оперировать решение. Мы сознательно пропускаем значимые discovery-этапы и активности бизнес-анализа, как-то анализ потребности, проработку бизнес-требований и пр. — все это, несомненно, важно, но не в контексте данной темы. А потому представим, что вы уже совместно с клиентом определились с тем, что и зачем вы будете делать.
То, что нужно рассмотреть как часть будущей картины данных портала, — это подчеркнутые в исходном тексте слова. Тренеры, клиенты — это, судя по описанию, Пользователи решения. Сюда же добавим Услуги — нечто, что Пользователи-тренеры будут предлагать Пользователям-клиентам. Для таких Пользователей, как Тренеры, будут Отзывы. На данном этапе работы с исходным текстом нам этого хватит. Опытный аналитик мог бы погрузиться и глубже — задуматься про механизм оплаты, админскую часть и прочие неявные блоки, которые он, исходя из опыта, уже видит по подобному описанию, но мы-то с вами неопытные и только-только учимся вычленять подобные частички. В общем, нехитрый анализ говорит нам о том, что в целевом портале на уровне данных в системе будут храниться (а если не храниться, то как минимум система будет оперировать ими в том или ином ключе) Пользователи двух видов (Тренеры и Клиенты), Услуги, привязанные к Тренерам, и Отзывы, привязанные к Тренерам и оставляемые Клиентами. Ну и огонь. Первичный анализ сделан.
2. Примените CRUDL ко всем объектам данных, которые вы видите на текущем этапе.
У нас в примере — некий начальный этап: мы ничего не знаем о наполнении системы, не считая краткого пассажа от клиента. Но вообще CRUDL как техника применяется на любом из этапов БА — стартуете вы проект и хотите прояснить его наполнение (скоуп) или обрабатываете CR в режиме поддержки уже работающей системы: всегда, когда появляется какая-либо хотелка, в которой вы можете вычленить кусок данных, вы можете применить к этому CRUDL, дабы убедиться, что как минимум по базовым операциям вы ситуацию с ЗЛ прояснили.
Как применять технику?
В интернете есть много вариаций, которые сводятся тупо к разной структуре таблиц, с помощью которых вы будете оформлять ваш CRUDL-анализ. Но имхо формат таблицы — крайне вторичная штука; на самом деле подобный анализ можно просто делать в голове, не документируя никак его ход. Давайте попробуем один из наиболее простых вариантов:
Определим, что из мнемоники CRUDL было затронуто в исходном тексте. Не обязательно буквально — подумайте, в виде чего в контексте вашего проекта скрывается та или иная базовая операция.
Как видим, затронуто в тексте было немного — у нас осталась куча незаполненных ячеек. И это прекрасно, в том плане, что CRUDL может очень и очень весомо нам помочь в устранении пробелов.
3. Сделайте что-то полезное с результатами анализа 😊
Звучит весьма общо, но на самом деле, что вы будете делать с тем, что вышло в предыдущем пункте (то бишь с очевидными претендентами на пробелы в требованиях), решать вам. Наиболее частым итогом будет сформулировать кучу вопросов клиенту или иным ЗЛ (конечным пользователям, в частности) и пойти их уточнять. Соответственно, на какие полезные вопросы навел нас CRUDL + наши навыки по его применению:
а) Какие категории пользователей будут в решении? Правильно ли понимаем, что отдельно будут клиенты и тренеры, при этом каждой категории будет доступен различный набор функциональности?
б) Нужно ли управление пользователями (создание, редактирование, удаление аккаунтов)? Если да, то, вероятно, со стороны некоего администратора, что таки выливается в еще одну категорию пользователей? Если нет, то как вообще вы видите попадание пользователей в систему? Нужна ли возможность самостоятельной регистрации (create «от себя») в системе для тех или иных категорий пользователей?
в) Нужен ли просмотр своих клиентов/своих тренеров (в плане истории взаимодействия) для тренеров/клиентов?
г) Как будет осуществляться управление предоставляемыми услугами для тренеров (создание, редактирование, удаление со стороны тренера)?
д) Может ли клиент отказаться от (удалить), поменять параметры (отредактировать) или просмотреть историю заказанных услуг?
е) Кто может оставить отзывы на услуги от тренера? Можно ли отзыв поменять или удалить?
На все это вы получите некие ответы, которые, вероятно, будут содержать новые элементы данных, по отношению к которым вы снова примените CRUDL, и т. п. Представьте теперь, насколько шире станет наполнение вашей системы по итогу, плюс представьте, что было бы, если бы ваша команда просто начала разработку исходного наполнения, не учтя пробелы или столкнувшись с ними потом в процессе (не во всех моделях разработки подобное критично, но зачастую такое очень больно бьет по проекту). И ведь всего-то нужно было – знать волшебные пять букв и немножечко подумать, применив их к известной вам информации.
Далее вы уже можете модифицировать CRUDL по своему усмотрению. С одной стороны, вы можете добавить в технику смысл «вглубь». Например, оценивать в явном табличном виде не только необходимость наличия операции в скоупе, но и сразу же доступность ее по правам доступа или ролям тем или иным категориям пользователей. Либо же вы можете видоизменить подход «вширь», добавив в него новые буквочки и сделав ваш чеклист типовых операций полнее (из часто встречающегося: S — sort, S — search, F — filter, M/C — move/copy). И тогда лично для вас CRUDL станет еще полезнее.
Суммируя, техника CRUDL — это инструмент в арсенале аналитика, который занимает одно из почетнейших мест в тех 20%, которые несут 80% ценности. Иными словами, это что-то очень дешевое и очень сердитое — применяется быстро и несложно, но дает не упустить те здоровенные куски, которые упускать при проработке требований критично. А мы такие вещи, конечно же, любим и ценим.
3. Сделайте что-то полезное с результатами анализа 😊
Звучит весьма общо, но на самом деле, что вы будете делать с тем, что вышло в предыдущем пункте (то бишь с очевидными претендентами на пробелы в требованиях), решать вам. Наиболее частым итогом будет сформулировать кучу вопросов клиенту или иным ЗЛ (конечным пользователям, в частности) и пойти их уточнять. Соответственно, на какие полезные вопросы навел нас CRUDL + наши навыки по его применению:
а) Какие категории пользователей будут в решении? Правильно ли понимаем, что отдельно будут клиенты и тренеры, при этом каждой категории будет доступен различный набор функциональности?
б) Нужно ли управление пользователями (создание, редактирование, удаление аккаунтов)? Если да, то, вероятно, со стороны некоего администратора, что таки выливается в еще одну категорию пользователей? Если нет, то как вообще вы видите попадание пользователей в систему? Нужна ли возможность самостоятельной регистрации (create «от себя») в системе для тех или иных категорий пользователей?
в) Нужен ли просмотр своих клиентов/своих тренеров (в плане истории взаимодействия) для тренеров/клиентов?
г) Как будет осуществляться управление предоставляемыми услугами для тренеров (создание, редактирование, удаление со стороны тренера)?
д) Может ли клиент отказаться от (удалить), поменять параметры (отредактировать) или просмотреть историю заказанных услуг?
е) Кто может оставить отзывы на услуги от тренера? Можно ли отзыв поменять или удалить?
На все это вы получите некие ответы, которые, вероятно, будут содержать новые элементы данных, по отношению к которым вы снова примените CRUDL, и т. п. Представьте теперь, насколько шире станет наполнение вашей системы по итогу, плюс представьте, что было бы, если бы ваша команда просто начала разработку исходного наполнения, не учтя пробелы или столкнувшись с ними потом в процессе (не во всех моделях разработки подобное критично, но зачастую такое очень больно бьет по проекту). И ведь всего-то нужно было – знать волшебные пять букв и немножечко подумать, применив их к известной вам информации.
Далее вы уже можете модифицировать CRUDL по своему усмотрению. С одной стороны, вы можете добавить в технику смысл «вглубь». Например, оценивать в явном табличном виде не только необходимость наличия операции в скоупе, но и сразу же доступность ее по правам доступа или ролям тем или иным категориям пользователей. Либо же вы можете видоизменить подход «вширь», добавив в него новые буквочки и сделав ваш чеклист типовых операций полнее (из часто встречающегося: S — sort, S — search, F — filter, M/C — move/copy). И тогда лично для вас CRUDL станет еще полезнее.
Суммируя, техника CRUDL — это инструмент в арсенале аналитика, который занимает одно из почетнейших мест в тех 20%, которые несут 80% ценности. Иными словами, это что-то очень дешевое и очень сердитое — применяется быстро и несложно, но дает не упустить те здоровенные куски, которые упускать при проработке требований критично. А мы такие вещи, конечно же, любим и ценим.
