Вводная или почему этот вопрос важен

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

Так уж получилось, что часто проверку качества приходится делать автору. Приносит мне аналитик постановку “программа должна делать это и это”. Проверить то, что в постановке нет логических ошибок можно, но как проверить, что это ПО - то, что нужно заказчику? 

Как устроен процесс: есть вводная от заказчика, а дальше происходит следующее - аналитик пишет детальные требования и модели решений. Почему именно такие требования и модели решений? Этого в ТЗ не написано. Когда спрашиваешь аналитика, он иногда говорит 

1. “ну это же логично”, не понимая, что есть масса других таких же логичных вариантов. Почему именно этот? Ответ чаще всего - “а я не знал, что другие варианты возможны”,

2. “заказчик сказал (требование), потому что (обоснование)”. Когда сказал заказчик зачем это нужно ему и почему сказанное им является обоснованием требования - неясно. 

В итоге,  проверить постановку на пригодность создаваемого ПО чаще всего нельзя. 

Когда просишь аналитика описывать зачем нужны описываемые требования и почему такие модели решения, то возникает проблема. Аналитик пишет что-то типа “поиск на сайте нужен, чтобы ускорить поиск товара на сайте”. Почему для решения задачи ускорения нахождения нужного товара для клиента требуется именно поиск - неясно. Есть и другие варианты нахождения нужного товара (каталог с фильтрами, опросник по потребностям, акционные страницы - к примеру). Описания обоснования требований часто недостаточны для их проверки. 

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

В итоге, я написал статью для аналитиков, чтобы они писали действительно обоснованные требования, а так же сделал выступление на конференциях (кому лучше воспринимать голос - смотрите тут https://youtu.be/aiLHlwvsakw ).

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

Содержание

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

2. В главе “Как давать определения” мы познакомимся с подходом, который позволит понять, что наше определение правильное и полезное.

3. Далее, в “Обоснование требования и потребность в литературе” мы соберем мысли авторов некоторых классических трудов, что они под этим подразумевают, как используют эти концепты.

4. В главе “Раскладываем по полочкам. Часть 1” мы разделим обоснования на функциональные + обоснования качества  и обоснования проекта изменения, имеющие меньшую значимость при проектировании.

5. Затем, в главе “Раскладываем по полочкам. Часть 2” мы разберемся с тем, является ли проблема и возможность обоснованием требований и поймем, что нет.

6. Глава “ Откуда берется обоснование требований для подсистем?” посвящена тому, что же на самом деле есть обоснование требований к подсистеме, где оказывается, что это не может быть требованием к системе. Иначе говоря, требование к системе не обосновывает требование к подсистеме.

7. В главе “Стейкхолдеры - источники требований?” мы окончательно проясним что есть обоснования требований и классифицируем стейкхолдеров и объективизируем их потребности.

8. В итогах мы подведем итоги.

Нужные понятия системной инженерии

Для решения поставленной нами задачи нужны удобные термины. Оказывается, что наиболее удобны термины системной инженерии. К сожалению, не все с ними знакомы, поэтому дадим краткий обзор.

Системой мы будем называть конструкцию из некоторых объектов, которые, взаимодействуя друг с другом, создают системное свойство - это свойство которое есть у системы в целом, но пропадает, если убрать из системы любую его часть (эмерджентность). Часть системы называем подсистемой. Системы, в которые данная система входит как часть, называем надсистемой.

Системы - это не только ИТ системы. Например, розничный магазин (система) создает продажи (системное свойство). Он состоит из

1. полок,

2. товаров на полках,

3. касс и кассиров,

4. проходов между полками,

5. роль “клиента в магазине” (клиентов нужно тоже учить как себя вести в магазине, не есть с витрины и т.п.) 

6. и пр.

Система обладает каким-то качеством (значениями атрибутов качества). Качество системы – это степень удовлетворения системой заявленных и подразумеваемых потребностей различных заинтересованных сторон, надсистем и взаимодействующих систем, которая позволяет, таким образом, оценить достоинства.

Обеспечивающая система для системы А - это системы, которые обеспечивают для системы А переход в задуманное состояние, при этом не являясь частью этой системы, например,

• создание (переход в состояние существования/эксплуатации/использования), 

• возврат в существование (при выходе системы из состояния нормального существования),

• управление, проведение изменениями и контроль (переход в новое существование с измененным качеством),

• и ликвидацию (если мы задумали вывести систему из эксплуатации).

Например, для магазина обеспечивающие системы - это

1. проект строительства,

2. найм персонала,

3. коммунальные услуги,

4. закупка оборудования,

5. определение цен (ценообразование),

6. обслуживание касс,

7. привлечение клиентов (клиентский маркетинг),

8. проекты реконструкции и закрытия и пр.

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

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

Рассматривая отношение использования, системы выстраиваются в ориентированный граф (в определенный момент времени, в определенных обстоятельствах).

Требованием (requirement) мы будем называть утверждение о (атомарном) свойстве системы, реализация которого должна помочь достижению цели.

Моделью системы мы будем называть упрощенное представление о системе для ее изучения или проектирования. 

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

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

Представьте, что вы называете модель требованием. Тогда придется говорить “мы проектируем требование, чтобы разобраться с тем, как будут выполнены требования”. Модель и требование - это разные мысленные конструкции, проектирование будет эффективнее, если их  разделять (подробнее - см. https://habr.com/ru/post/696562/ ).   

Подход top-down проектирование - это подход, при котором вначале проектируется модель использующей системы, а затем всех используемых. 

Например, в ритейле порядок проектирования может быть таким:

1. модель деятельности клиента, а затем модель продукта для этой деятельности (подход  JTBD),

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

3. модель привлечения клиентов для продажи продуктов,

4. модель способов привлечения, например, промоакцию 3=2.

Почему важен top-down? Например, для промоакции крайне важно знать, какой товар будет продаваться. Например, 3=2 для автомобильных шин или гвоздей не имеет никакого смысла.

Кстати, top-down проектирование для шага “спроектировать модель продукта” работает не через полное изучение рынка, так как рынок обычно крайне разнообразен, каждый клиент имеет в чем-то свою модель деятельности. Обычно происходит так - вы узнаете модель деятельности у небольшого числа клиентов через custdev, проектируете продукт, а затем уже обратно выясняете рыночный сегмент для этого продукта) (более полная версия этого феномена будет описана в последующих статьях). 

При проектировании важен контекст окружения (взаимодействующие системы, не в области нашего проектирования). Например, продажа товаров в самолете устроена совсем по другому нежели на твердой земле.

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

Подробнее о задаче аналитика-проектировщика : https://habr.com/ru/post/529236/

Нужные термины определены, давайте приступим к основной части.

Как мы будем понимать определение

Поскольку мы взялись определить понятие “обоснование требований” нужно договориться о том, как собственно давать эти определения и понимать их.

Гораздо удобнее и понятнее сказать “купи что-то, чтобы сидеть вдвоем вместе и комфортно смотреть телевизор”, чем “купи вещь, h-образной формы в профиль, с высотой 50 см, глубиной 50 см, имеющий определенный уровень мягкости, имеющий угол между и т.п.….”. В первом случае вам наверняка купят диван, а вот во втором могут купить и стул, потому что вы забыли про требование ширины. Описать назначение в использовании компактнее, чем описать все нужные свойства объекта.

Иными словами, определить какую-то вещь проще и понятнее прежде всего через ее использование/через ее назначение в использовании.

Абстрактную конструкцию понять достаточно сложно, если нет примеров. “Это, это и это - диван, а это, это и это - не диван” - наиболее простой способ понять что такое диван (в совокупности с описанием назначения использования).  

Подробнее про то, как передавать смысл описано в статье https://habr.com/ru/post/691604/ .

Итого, давать определение “Обоснование требования”/“Потребность” мы будем разбираясь с тем, как используется этот термин, какую ценность он несет в конкретных примерах его применения.

Обоснование требования и потребность в литературе

Давайте посмотрим в литературу и соберем все случаи использования термина “Обоснование требования”/“Потребность”, разберемся какую ценность применения термина получают авторы.

В SEBoK написана форма user story “ Я как стейкхолдер, хочу требование, чтобы потребность”. Потребность в этой форме обосновывает требование. Неясно, все ли обоснования требований можно назвать потребностями.

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

Потребность обычно понимается, как понятие из маркетинга и психологии. Например, первичные потребности:

• безопасность,

• здоровье,

• питание,

• сон и т.п.

В англоязычной бизнес литературе появляется термин “business needs” или просто “needs”, который имеет более широкое толкование.

Например, BABOK 3.0

“solution: A specific way of satisfying one or more needs in a context.” имеется ли тут в виду, что needs in a context - это условия задачи, решения которой нужно найти в широком смысле (не только проблемы конкретного стейкхолдера) - неясно. “business needs” обосновывают “business requirements”. Является ли при этом “business needs” тем же самым понятием из маркетинга и психологии неясно, так как примеров в этой книге нет.

Давайте пробовать искать смысл более широкого толкования термина “потребность”.

В книге К. Вигерса термины потребность и требования смешаны. “Термин бизнес-требования (business requirements) относится к информации, которая в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат.” (с), с.87. 

В книге Ф.П. Тарасенко “ПРИКЛАДНОЙ СИСТЕМНЫЙ АНАЛИЗ” определения потребности нет.

SEBoK v.2.5: …The RE or BA may use a fully or partially structured process to elicit specific needs, as described in models such as user stories, use cases, scenarios, system concepts, and operational concepts….

BABoK v.3. A problem or opportunity to be addressed. Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or enhancing the value delivered by existing solutions.

Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

Примеров, увы, опять нет.

В. Мизгулин, “Системный инженер. Как начать карьеру в новом технологическом укладе”. 

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

Я, как <стейкхолдер>, хочу <потребность>, потому что <проблема>.

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

“Потребность должна оставаться актуальной вне зависимости от целевой системы. Пользователь хочет платить меньше независимо от существования умного дома. Требование актуально относительно целевой системы и ее элементов. Будем использовать следующую переходную конструкцию от потребности к требованию: 

Я, как <стейкхолдер>, считаю, что система должна <требование>, чтобы <потребность>.

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

Итого, когда авторы говорят про концепт “потребность” и использование этого концепта, то они говорят про

1. Проблему или возможность,

2. Мотиватор действия стейкхолдеров, 

3. Обоснование создания/изменения системы,

4. Вводные для проектирования,

5. Обоснование требования,

6. Существование вне зависимости от системы.

Давайте пройдемся по этим назначениям использования и поймем что чем является.

Раскладываем по полочкам. Часть 1

Мы получили шесть смыслов термина “Потребность” (один из которых “Обоснование требования”). Давайте посмотрим на конкретном примере, что это такое и сделаем выводы, что нам непосредственно полезно при проектировании, а что имеет косвенную ценность. 

Жил был один ритейлер и решил он заменить обычные ценники в магазинах на электронные. 

В чем и у кого потребность “электронного ценника”, что является обоснованием их работы и их появления ?

Если мы выпишем все мысли “зачем нужен электронный ценник”, которые приходят в голову, то мы получим список

1. чтобы быстро менять цену/промо, 

2. чтобы вводить промо каждый день,

3. чтобы лучше вовлекать клиентов, 

4. чтобы увеличить прибыль,

5. чтобы сократить издержки на замене ценников,

6. чтобы отображать цены, наличие и условия промоакции.

Разложим эти “чтобы” на карте иерархии систем

1. Главная функция электронного ценника - обеспечивать процесс выбора товара клиентом информацией по цене и акции (6. отображать цены, наличие и условия промоакции).

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

3. ИТ-система “Электронный ценник” обладает следующим качеством : она позволяет изменять цены и скидки на ценнике удаленно, скорость изменения не зависит от количества этих ценников (незначительно зависит). (1. быстро менять цену/промо)

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

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

6. Проведение большего количества промо-кампаний подогреет интерес клиентов (3. лучше вовлекать клиентов), которые будут покупать больше, тем самым увеличивая оборот и прибыль компании (4. увеличить прибыль).

В этом рассуждении есть ключевой момент. Допустим, мы установим ценники и сделаем более производительную замену ценников. Но что если при этом:

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

2. появившееся дополнительное время у мерчандайзеров не будет приводить к улучшению качества представления товара магазина, или не будет приводить к уменьшению расходов на персонал (никого из мерчандайзеров не уволили и не перевели на почасовую оплату с уменьшением ФОТ).

В этом случае изменение было бессмысленным, автоматизация ради автоматизации не имеет смысла. Таким образом оправдание необходимости проекта всегда описывается в терминах улучшения атрибутов качества бизнес-процессов.

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

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

Обоснование будущей функции или качества системы “Ценник”.  

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

2. Обоснование качества системы. Нам требуется высокопроизводительная замена ценников, чтобы проводить массовые акции.

Обоснование проекта изменения. 

1. Увеличение производительности замены ценников, что позволит проводить более частые и объемные промо-кампании, что позволит увеличить вовлеченность клиента и повысить прибыль и обороты компании.

2. Уменьшение расходов на персонал, уменьшение их времени использования в случае почасовой оплаты. 

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

Итого, обоснования системы разделяется на два вида обоснований

1. Обоснование функции и ее качества. Это обоснование позволяет спроектировать какой должна быть сама система.

2. Обоснование изменения системы и связанных систем, обоснование проекта.  Это обоснование позволяет доказывать необходимость этих изменений. 

P.S. Теперь мы можем привести примеры удачных и неудачных user story, понимая в чем причина неудачи.

Примеры неудачно сформулированных user story: 

1. нам нужен каталог товаров на сайте, чтобы ускорить нахождение нужного товара клиентом (что тоже самое, чтобы быстро находить товар),

2. нам нужны фасетные фильтры в каталоге товаров на сайте, чтобы ускорить нахождение нужного товара клиентом,

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

4. нам нужно сравнение товаров на сайте, чтобы ускорить нахождение нужного товара клиентом.

Примеры удачно сформулированных user story:

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

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

Раскладываем по полочкам. Часть 2

Итак, исходные варианты назначения концепта “потребность” разложились на:

1. Потребность изменения:

   1. Мотиватор действия стейкхолдеров, 

   2. Обоснование создания/изменения системы,

2. Потребность для проектирования:

   1. Вводные для проектирования,

   2. Обоснование требования,

3. Что то неясное:

   1. Существование вне зависимости от системы,

   2. Проблему или возможность.

Давайте выясним, что такое “Проблема или возможность” на том же примере.

В чем проблема или возможность, связанная с электронными ценниками?

Для этого могут быть следующие соображения:

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

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

Является ли подобная проблема или возможность “потребностью” ? 

У стейкхолдера существует потребность решить проблему / разобраться с возможностью, это мотивирует его действовать. Почему?  Потому, что у него есть потребности безопасности (уволят), признания, самореализации и пр. возникающая из-за того, что ему поручили или он взял на себя такую роль. Для закрытия таких потребностей стейкхолдер решает (сам или поручает кому-то) или создает видимость процесса решения такой задачи.  Но можно ли назвать саму проблему/возможность потребностью или обоснованием действия стейкхолдера? Мне так не кажется (причина действия стейкхолдера - потребность безопасности, самореализации и пр., проблема или возможность - это контекст, ситуация, которая вызывает действия). 

Если мы попробуем указать на место, где возникают проблемы или возможности на карте систем, то обнаружим, что они могут возникнуть почти везде:

1. В надсистеме для бизнеса, может быть проблема/возможность в модели использования бизнеса либо в качестве этой надсистемы,

2. Проблема или возможность может быть в системе “Владелец бизнеса” (владелец перестал участвовать в управлении или наоборот начал участвует),

3. Качество бизнеса может быть таким, что представляет собой проблему для надсистемы или владельца,

4. Бизнес-модель может представлять собой проблему; возможность может быть в новой бизнес-модели,

5. Проблема может быть с клиентами, возможность может в новом сегменте рынка или в новом взаимодействии или продукте с существующими клиентами,

6. Проблемы/возможности могут быть с исполнителями или моделью их взаимодействия (ролью) с бизнес-процессами и ИТ системами,

7. Проблема/возможность может быть в моделях исполнения бизнес-процессов, качестве их исполнения,

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

9. и т.д.

То есть проблема или возможность, вызвавшая наше изменение, может возникнуть в любом месте иерархии систем, не создавая непосредственное влияние на требования к проектируемой нами системе. Таким образом проблема или возможность не может обосновывать почему именно такое требование накладывается на систему (исключение - если проблема или возможность связана непосредственно с нашей системой или моделью ее использования).

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

Сама по себе проблема или возможность не обосновывают требование.

• Проблема чаще всего фиксирует что плохо, но не является описанием “как должно быть хорошо” (для этого нужна цепочка проектирования), поэтому проблема не дает нам непосредственного понимания как должна работать система,

• Возможность чаще всего не является требованием и не обосновывает его (за исключением, когда возможность - это осознание новой модели использования системы). Нельзя сказать “система должна работать так-то, потому что новая технология или новый рынок”, так как есть промежуточный уровень проектирования модели использования, который поясняет как новая технология создает новые модели системы, обладающие лучшим качеством, какая модель использования продукта на новом рынке и пр. 

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

1. Потребность изменения:

   1. Мотиватор действия стейкхолдеров, 

   2. Обоснование создания/изменения системы.

2. Потребность проектирования:

   1. Вводные для проектирования,

   2. Обоснование требования.

3. Не потребность/не обоснование требований (факты для инициации процесса проектирования):

   1. Проблему или возможность.

4. Определим позже

   1. Существование вне зависимости от системы.

Откуда берется обоснование требований для подсистем?

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

Вспомним форму user story. Я как стейкхолдер, хочу требование, чтобы “потребность/обоснование требования”.

Пока отложим вопрос, как связаны стейкхолдеры и потребности и рассмотрим случай, когда система является частью какой-то надсистемы. В некоторых книгах (в частности SEBoK) в этом случае потребностью называют требование к надсистеме.

Рассмотрим систему “Ножницы” и “Гвоздик” - часть системы “Ножницы” (ИТ система в автоматизации бизнеса не имеет самостоятельной ценности, точно также как гвоздик в ножницах). 

1. Гвоздик нужен, чтобы резать бумагу (требование к надсистеме, к ножницам).

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

Какое обоснование лучше обосновывает необходимость гвоздика? Первые выглядит несвязным. Второе выглядит убедительнее.

Рассмотрим более сложный случай.

Жил-был контакт-центр. Его назначение/функция - отвечать на вопросы клиентов (функциональное требование к контакт центру). После анализа тематик вопросов оказалось, что 30% всех звонков - это звонки о запросе текущего баланса бонусов (контекст). Технологическая возможность синтеза речи (возможность) создает возможность автоматизации - сделать так, чтобы робот зачитывал текущий баланс в IVR (модель решения). 

Требование к ИТ системе IVR : информировать клиента о балансе бонусных баллов в процессе звонка. В чем причина такого информирования?

Информировать нужно, чтобы

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

2. вариант 2. Выбрать когда нужно купить товар, с учетом того, что бонусы скоро сгорят (тут мы понимаем, что помимо бонусов нужно сказать дату сгорания). Это нужно, чтобы использовать накопленные выгоды, не потерять их, чтобы не допустить негативной эмоции “потери бонусов” (любимый трюк маркетологов).

Выбрать, где купить нужный клиенту товар - это фактически сжатое описание того, как клиент выбирает из нескольких вариантов покупки у разных продавцов (наличие конкурентного рынка подразумевается). Это описание модели процесса выбора. Зачем это делается ? Чтобы купить с минимальной стоимостью - это требование к процессу выбора. Возможность сэкономить при покупке - это ценность = требуемое свойство системы процесса выбора (требование качества к системе - процессу выбора). 

Во втором варианте происходит тоже самое. Выбрать когда купить предполагает модель процесса выбора “выбрать что-то, куда можно потратить большую часть бонусов к определенному времени”. Не потерять накопленные выгоды - требование к этому процессу. Не допустить негативной эмоции - первичная потребность клиента (про них посмотрим далее).

Мы помним, что потребность должна быть существующая, независимо от наличия системы, и это значит, что мы получаем вывод.

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

P.S. Новые требования к использующей системе как раз являются, чаще всего, обоснованием проекта. В этом случае, цепочка взаимосвязей требований и обоснований будет такой: 

1. от системы требуется требование,

2. чтобы при таком то взаимодействии системы со смежными системами (модель решения),

3. использующая система становилась лучше, удовлетворяла новым требованиям к использующей системе,

4. поэтому проект изменения имеет смысл.

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

Стейкхолдеры - источники требований?

Ну и наконец, давайте поймем, что есть причина требований стейкхолдеров, возможно ли определить их объективную причину и уйти от рассуждений “Потому что я так хочу”, “ну мне так кажется”, “почему бы и нет”, “красиво, значит правильно”.

В литературе описано - узнайте у стейкхолдера его потребности, превратите их в требования и вуа-ля, требования собраны (утрировано).

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

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

Кстати, почитайте М. Гаулстона “Я вижу вас насквозь”, там описано, как техника объективизации потребностей помогает работать в переговорах. Феномен фундаментальной ошибки атрибуции - тоже про объективизацию проблематики.

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

Рассматривая деятельность стейкхолдера мы можем выделить варианты.

Вариант 1

Деятельность, относительно которой есть интерес - это и есть разрабатываемая система (бизнес-процесс)

Есть несколько случаев:

1. В случае если стейкхолдер - сотрудник компании, то у него есть назначенная ему роль, предполагающая защиту некоторых интересов компании (вашей компании или компании вашего партнера или клиента). Сюда же можно отнести все случаи, когда стейкхолдеру вменили защиту какого-то внешнего интереса, например отец, отправляя сына за продуктами говорит “купи такие-то продукты подешевле”, поручая ему соблюдать интерес “дешевле” в рамках надсистемы “семья”.

2. У стейкхолдера может быть личный интерес.

Рассмотрим первый случай. 

Например, мы проектируем промоакцию “3 по цене 2-х”. В РФ действует закон, согласно которому покупатель может вернуть товар за ту стоимость, которая была распечатана на чеке. А значит, если на чеке распечатать 100% скидку на третий товар, то покупатель может вернуть первые два и получить третий товар бесплатно.

Финансисту компании это не нравится, он защищает интерес компании минимизации потерь. Исходя из него мы проектируем модель решения - “размазывать стоимость наиболее дешевого товара по всем трем, пропорционально стоимости”, которая дает минимальные потери при возврате любого товара (при условии одинаковой вероятности возврата любой вещи).

Любой финансист любой компании защищает интерес минимизации потерь, поэтому сформированное нами решение подходит в любой компании, где применима эта акция (и где примерно одинаковая вероятность возврата любой вещи). 

Спрашивать у финансиста “зачем компании нужно минимизировать потери” непродуктивно (на вас посмотрят как на идиота). Это интерес не требует доказательства.

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

Разумеется, знание интересов компании не избавляет от необходимости находить стейкхолдеров и согласовывать с ними требования, но это позволяет обсуждать их и дополнять их. Хотя бывают случаи, когда представителей просто нет, а проектировать надо, в этом случае можно опираться на свое представление требований на базе интереса - это лучше чем вообще без требований. К примеру, для акции “3 по цене 2-х” лучше применить модель “размазывать стоимость наиболее дешевого товара по всем трем, пропорционально стоимости”, чем “на каждый третий дешевый товар скидка 100%”, даже если финансиста не нашлось. Вас нанимают, потому что вы обладаете опытом, что и предполагает знание типовых интересов компании и разных моделей решений с учетом этих интересов.

Случай 2. Личный интерес стейкхолдеров - это те самые потребности из психологии или порожденные потребности. Они так же объективны (но не всегда осознаны/не всегда объяснены).

1. Владелец компании, как правило, выражает требования к компании исходя либо из потребности самореализации и других потребностей пирамиды Маслоу (либо требование к компании возникает исходя из использования результатов деятельности компании в какой-то использующей системе),

2. Сотрудник, как личность, как правило, имеет простые потребности удобства (минимальное количество действий для достижения цели), эстетики и пр. Эти потребности универсальны = переносимы между компаниями,

Вариант 2

Деятельность стейкхолдера взаимодействует с проектируемой системой.

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

Например, мы проектируем систему - бумажный ценник в магазине с напечатанным промостикером.

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

Почему такое требование - можно раскрутить дальше. Это время заложено в модели рабочего времени сотрудников, предполагающая найм сотрудников на смену определенной длительности итого (следующая по цепочке модель решения), так как превышение этого времени повлечет увеличение оплаты ФОТ (требование к модели использования рабочего времени) и так далее до влияния на прибыль компании.

Понимание этой модели (потребности) дает понимание деталей и вариантов действий (если нас это требование не устраивает):

1. допустимое количество к замене можно увеличить, если промотовары находятся рядом,

2. можно поменять формат промостикера, чтобы оклейка была быстрее,

3. можно заменить оборудование для печати и программу управления оклейкой,

4. можно все таки доплачивать иногда сотрудникам, если эти случаи редки, а выгода от применения промо превышает доплаты.

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

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

А что если стейкхолдер - это клиент

Если мы рассмотрим стейкхолдеров на стороне клиента, то обнаруживаем сразу все варианты причин потребностей

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

2. клиент-покупатель имеет личный интерес “побыстрее”, “с меньшими трудозатратами”, “с меньшими мыслезатратами” произвести выбор и покупку,

3. клиент-потребитель использует ваш продукт в рамках какой-то модели использования (JTBD), создавая какую-то ценность, именно модель использования является причиной требования и дает подсказку каким должен быть продукт.

Так нужны ли стейкхолдеры для проектирования ? Да - они активные участники - выразители интересов и текущих/будущих моделей своих систем. Сами системы про себя не расскажут.

Подитог

Стейкхолдер выражает причины/обоснования требований, которые являются

1. личными интересами,

2. назначенными интересами в пользу какой-то компании или другого стейкхолдера,

3. моделями использования какой-то системой.

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

Итого

Любой ответ на вопрос “чтобы что” и “зачем” - это причина/обоснование того, что требуется. 

Причины/обоснований требований - это на самом деле

1. личный интерес стейкхолдера (по моделям потребностей из психологии),

2. назначенный стейкхолдеру интерес со стороны бизнеса или другой надсистемы,

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

При этом обоснование должно включать в себя описание момента и контекста/ситуации возникновения требования.

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

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

Кроме того, понимание причин требований, вместе с ограничениями годности моделей решений дают возможность переносить эти модели решения между разными проектами для разных бизнесов, что позволяет значительно сократить процесс проектирования. Некоторым аналитикам это не по душе, так как процесс проектирования с нуля интереснее процесса применения шаблонных решений, но заказчику важен результат (у кого деньги тот и прав). По мнению автора, стоит владеть обоими стилями “кунг-фу”.

В статье не раскрыты причины / обоснования требований качества и обоснование ограничений - есть простор для дальнейших статей.

Благодарности

1. Спасибо Денису Бескову за материалы и помощь в осознании некоторых моментов 

2. Спасибо Сергею Мартыненко за очень многое, всего и не пересказать

3. Спасибо Анатолию Левенчуку за хорошую книгу и курсы

4. Спасибо членам клуба им. Ф. Бекона за критику материалов и новые идеи

5. Спасибо Александру Турханову за ссылки и за ответы на вопросы

6. Спасибо Александру Лучкову за прояснение некоторых моментов и терпение в структуризации материалов и ссылки на литературу

7. Спасибо Эдуарду Галиаскарову за ценные замечания и ссылки

8. Спасибо Владимиру Завертайлову за статью со сравнением подходов Job To Be Done

9. Спасибо авторам перечисленных книг за ваш труд

10. Спасибо Михаилу Килофяну на рецензирование статьи,

11. Отдельное спасибо коллегам из AWG за поддержку и рецензирование статьи.