Каждый раз, когда приходится стартовать проект с нуля, не перестаю удивляться количеству вещей, про которые нужно подумать и принять решение. В первый раз, помню, поразился, когда понял, что разные виды обеспечения из ГОСТ 34.602 — это не "вода", как многие считают, а реально нужные и полезные разделы. Например, правовое обеспечение системы, или лингвистическое (за казенными формулировками не всегда понятно, что "лингвистическое обеспечение" — это, в том числе, тот самый ubiquitous language из DDD, а вовсе не "подписи в интерфейсе системы должны быть выполнены на русском языке").

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

И вот опять понадобилось выписать набор вопросов, по которым нужно принять решение и зафиксировать его:
1. Что нужно сделать? Какую возможность эксплуатируем / проблему решаем, почему сейчас, почему разработка программ поможет, какие есть ограничения? (первоначальное ТЗ)
2. О чем вообще мы говорим? (Глоссарий)
3. Что происходит? (Верхнеуровневая схема процесса, перечисление основных шагов)
4. Кому это нужно и зачем? (Реестр стейкхолдеров, их интересов и уровня влияния)
5. Как мы организуем работу? (Модель SDLC, подход к управлению задачами и релизами, выбор технических решений по ведению списка задач, хранению знаний проекта, фиксации решений, коммуникации. То есть, буквально: работаем недельными спринтами, релиз в конце каждого спринта, задачи записываем в Jira в виде юзер-сторей, а потом бьем на задачи для фронта и бэка, исходники храним в Gitlab, еженедельно созваниваемся по следующим вопросам, текущая переписка в таком-то мессенджере)
6. Как мы принимаем решения? (Регламент по приему различных решений: бизнесовых, организационных, по ахитектуре и функциям системы)
7. Что нужно сделать? (Описание функций системы)
8. Как это должно работать и изменяться? (Нефункциональные требования и характеристики)
9. Что из готового мы можем использовать / купить? (Политика использования готовых компонентов и сервисов)
10. С чем нам нужно будет интегрироваться или обмениваться данными? (Внешнее окружение)
11. Как это будет выглядеть снаружи? (Функциональная архитектура)
12. Как это будет устроено внутри? (Техническая архитектура)
13. Как мы это будем развертывать и обновлять? (Описание процессов развертывания)
14. Как мы будем предъявлять результаты работы?
15. Как мы докажем, что сделали то, что нужно и хорошо? (ПМИ в каком-то виде)

15 пунктов, я уже устал писать, а мы ведь не коснулись основного содержания работы аналитика — все эти спецификации требований, данных, экранов, API — и очень далеки от программирования. Каждый из пунктов раскрывается глубже и глубже: ок, мы выбрали, как будем фиксировать задачи, а какие поля должны быть у каждой записи о задаче? Какая у неё статусная модель? Какие условия переходов между статусами и кто должен быть информирован о них?.. Фактически, речь идёт о проработке требований к нескольким обеспечивающим системам. Да, скорее всего мы не будем их самостоятельно разрабатывать, но требования (решения) в их отношении мы должны принять. Хорошо тем, у кого эти решения уже приняты раз и навсегда, и новый проект стартует по готовым шаблонам. Но и проекты бывают разные — они же уникальные, и что подходит для одного проекта, может быть неудобным в другом. Начинай с начала!

А так как это решения, здесь должен быть выбор — ну хотя бы из двух вариантов (а в реальности их обычно больше). И каждый выбор должен быть обоснован — почему выбрали это решение и отвергли альтернативы? Если написать хотя бы 2-7 страниц по каждому пункту, это уже документ под сотню листов! А мы ещё не начали толком ничего делать. И работа по проработке требований к обеспечивающим системам проекта обычно остается невидимой.

Знаете, что меня больше всего бесит в процессах "типа agile"? Неприкрытый формализм. Особенно ярко это проявляется в регулярных событиях, которые предписывает, например, Scrum (в Kanban они тоже есть). Подавляющее большинство людей вообще не понимают их смысла.

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

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

События в Scrum не зря называются "церемониями" или "ритуалами" (хотя в Scrum Guide они нзываются просто "событиями", но Майк Кон в выступлениях их называл "церемониями"). Сам термин "церемония" применительно к регулярным встречам появляется ещё у Алистера Коберна (да, того самого, который написал Effective Use Cases) в Crystal Methods в 1990. И они вообще не про для того, чтобы узнать, кто над какой задачей работает или спланировать, что мы берем в следующий спринт.

То есть, и для этого тоже, но в первую очередь для другого. Ритуалы нужны (и спонтанно возникают) в сплоченных командах. Собственно, команд без ритуалов не бывает, также как без внутренних мемов и собственного языка, понятного только членам команды. Поэтому основная цель церемоний в Agile — это синхронизация сплочение команды. Не напоминание о задачах, а напоминание, кто мы такие и зачем мы тут собрались. Не контроль текущих работ, а рост уверенности в том, что о проблемах можно говорить открыто, доверие и вовлеченность всё ещё с нами, и тебе помогут, если что-то не получается. В конце концов, напоминание от том, что для нас важно и как мы тут вообще работаем, по каким принципам.

Строго говоря, все ритуалы направлены на изменение человека. Они для этого и нужны. После ритуала человек чувствует общность, принадлежность, спокойствие, сосредоточенность, поддержку, облегчение, снижение тревожности и повышение уверенности, гордость за свою работу — в общем, разные позитивные чувства. Причем это же регулярная практика, значит, чувствует он их регулярно, что позволяет как-то дальше протянуть в этом сложном мире. Если вы — ну, вдруг — проектируете процессы разработки, обратите внимание на ритуалы, и задайте себе вопрос: каким человек приходит на этот ритуал и каким уходит? Что в нем должно поменяться? А если у вас в результате встречи меняются не люди, а статусы задач в бэклоге, кажется, вы что-то упустили.

Задачи и так как-нибудь сделаются, а вот атмосфера в команде сама склонна скатываться куда-то не туда, особенно под давлением. И чтобы её выправить, нужно предпринять усилия, вкачать в систему энергию.

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

Короче, вот вам хороший диагностический признак — чувствуете ли вы подъем после ежедневного / еженедельного ритуала, или опустошение? Вот и ответ — agile у вас или что-то совсем иное.

В одном из обсуждений поста про ритуалы и дейлики возникла тема про доверие. Человек отреагировал очень резко: синхронизация под запись в чате?! Да никогда! Это же всё сохранится и может быть заскринено и использовано!

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

Тренеры по лидерству тут любят вспоминать Патрика Ленсиони и его книгу "5 пороков команды" (дисфункций), где он описывает пирамиду "пороков": отсутствие доверия ➜ боязнь конфликтов ➜ необязательность ➜ избегание ответственности ➜ безразличие к результатам.

Как любая вертикальная теория, эта пирамида описывает всё в упрощенном виде, но сами по себе эти "пороки" я вижу в командах очень часто. Конечно, всё не так просто, и научные модели дают более комплексную картину. Например, сами по себе конфликты могут быть и продуктивными, и деструктивными. Умеренные конфликты по поводу выполнения задач, или "конфликты идей" наилучшим способом оказывают скорее полезное влияние на общий результат (к таким конфликтам относятся разные взгляды на выбор технологического решения, например). Затяжные "процессные" конфликты скорее вредят (конфликты, связанные с логистикой задач и данных, процедур принятия решения и распределением ответственности). Межличностные конфликты вредят в любом случае (сюда же относятся конфликты целей, норм и ценностей).

Конечно, мы исходим из предположения, что у всех членов команды одна общая цель или цели хотя бы взаимосвязаны — если выиграешь ты, выиграю и я, без этого конфликты вообще сложно решить. Ещё важно, кто во что верит и как оценивает ситуацию — как win-win, или как win-lose. Особенно удивительно видеть, когда представители бизнес-заказчиков начинают бодаться с разработкой, рассматривая этот конфликт как win-lose. В отдельных случаях встречаются даже персонажи, находящиеся в парадигме lose-lose: "Ура! Всем плохо!".

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

Если помножить это на внешние факторы, связанные с недостатком ресурса или неопределенностью, ситуация становится взрывоопасной.

Факторы внешнего давления:
1. Проекты с высоким риском / ставками
2. Двусмысленные, плохо разграниченные роли и области ответственности
3. Несколько начальников с противоречивыми требованиями
4. Использование сложных технологий с запутанными связями
5. Нереалистичные сроки
6. Недостаток ресурсов
7. Недостаточное финансирование
8. Некомпетентное руководство

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

За летними делами пропустил историческую новость: в протокол HTTP добавили новый метод! Не каждый день бывает.

Добавление свежее, июньское, RFC 10008. Статус у него — Proposed Standard, но с таким статусом множество технологий живет, это значит — в целом норм, можете уже реализовывать в своих системах. В Nginx новый метод уже поддерживается. Называется этот метод QUERY. используется он примерно так:

QUERY /products/search HTTP/1.1
Host: api.example.com
Content-Type: application/x-www-form-urlencoded
Accept: application/json
q=distributed+systems&category=books&min_year=2025&sort=relevance

То есть, это фактически официальный GET с телом.

Проблема была в чем: если вы хотите найти что-то по сложному условию и множеству параметров, можно использовать GET, но параметры поиска можно передать только в строке запроса. Тела запросам GET не положено — его можно передать, но сервер или любой промежуточный узел может это тело проигнорировать и дальше не передавать. Строка запроса обычно ограничена по длине, есть даже специальный код ответа 414 URI Too Long.

GET безопасный, идемпотентный и кэшируемый.

POST небезопасный, неидемпотентный и не кэшируется. Зато у него может быть тело большого размера.

QUERY объединяет самое лучшее: он идемпотентный, безопасный, может кэшироваться и содержать тело. Заодно не оставляет следов в логах (что там было в теле — не видно). Так что если ваши запросы были слишком специфичны — теперь для них есть специальный механизм.

В каком именно формате вы будете передавать запрос в теле, стандарт не задает, но требует, чтобы вы явно указали это в заголовке Content-Type.

Там есть всякое интересное:
application/x-www-form-urlencoded — это строка запроса из URL
application/sql — SQL-запрос (вот так, прямо через REST API)
application/jsonpath — для вытаскивания специфических данных из JSON
application/xslt+xml — то же для XML
application/graphql — запрос в формате GraphQL
application/sparql-query — запрос в формате SPARQL
и т.д.

Можно спросить у сервера, в каких форматах он готов принимать запросы (он ответит в заголовке Accept-Query).

Можно ещё добавить Accept, то есть, например, в одном эндпоинте передавать простые запросы через строку, а для сложных переходить на SQL (теоретически), и получать ответ либо в JSON, либо в CSV (если сервер умеет). Всякую интересную логику можно реализовать.

Начинают играть коды ответов, про которые никто и не помнил:
415 Unsupported Media Type — сервер не поддерживает этот формат запроса к этому ресурсу
422 Unprocessable Content — сервер поддерживает этот формат, синтаксис запроса валидный, но выполнить его невозможно (например, нет такой таблицы, к которой обращается SQL)
406 Not Acceptable — клиент запросил ответ в таком формате, который не поддерживается сервером.

Сервер может даже создать новый ресурс, содержащий результат выполнения запроса! Как явный кэш, или как снэпшот на определенное время. Вернуть ссылку на него клиенту в заголовке Content-Location, а дальше к нему уже можно делать обычный GET. Сам QUERY при этом остается безопасным — новых ресурсов при повторных вызовах создаваться не будет.

Вот такая штука. Слышали уже? Планируете использовать?

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

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

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

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

Так нам говорит теория соц.исследований. UX-исследования, в сущности, специальная область применения таких исследований. Мне стало интересно — есть ли в UX исследования провокацией? И, представьте себе, есть! Даже термин для этого есть: provotype (provocation + prototype, провокационный прототип).

Это как бы доказательство от противного: что для пользователей действительно важно, а с чем они готовы мириться (а может быть, радикальные изменения, на которые никто не мог решиться, наоборот будут удобны!)

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

В одной статье описан провотип, который был сделан, как хоумпейдж из 90-х: с Comic-sans, желто-розовый и с gif-анимациями. Это был прототип сайта налоговой службы. В обсуждении быстро стало понятно, что именно тут кажется неуместным заказчикам и пользователям. Это ещё один принцип: не спрашивайте, что нужно и что удобно, спрашивайте — что мешает. В таких вариантах провотипа используется явно неуместный объект, не отсюда. Иногда присутствие такого объекта заставляет задуматься, а так ли он неуместен?

Ещё один вариант: против правил. "У нас всегда...", "Система не позволяет...", "Пользователь привык, что...". А что если нет? Что если мы подвергнем сомнению этот принцип, и сделаем наоборот?

Близко к этому примыкает тонкий прием, когда в прототипе что-то заведомо неправильно. Например, одна и та же информация представлена в двух вариантах, без какого-то объяснения. Исследователь фиксирует — а заметил ли вообще это пользователь, и какой вариант лучше? Возможно, информация неконститентна (и это специально). Многие дизайнеры вообще не следят за консистентностью, и иногда это можно обратить на пользу. Например, однажды дизайнер нарисовал интерфейс, в котором у ученика 6-го класса были выведены результаты ЕГЭ. Ух, мы много новых требований вытащили из этого прототипа!

Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её.

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

Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации.

Какие тезисы внутри:
🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок.
🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию.
🔸Цель системы, как правило, не выражена явно. Всё наоборот, да?
🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности.
🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих.
🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции.

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

В общем, это всё очень интересно с точки зрения внедрения изменений в организациях и обществе, но к ИТ-системам имеет отдаленное отношение. Для ИТ-систем это всё начинает работать, только если мы включаем в рассмотрение команду поддержки и разработки системы — тех, кто как раз получает обратную связь о работе системы и может её менять. Если рассмотреть всё вместе: ИТ-систему, технические средства и команду разработки, а ещё лучше — управленческую и политическую обвязку — то принципы Медоуз начнут работать. Именно в управленческом или лидерском аспекте. Может быть также полезно посмотреть с этих позиций, если вас интересует — как изменится деятельность организации после внедрения какой-нибудь системы. Это уже для правильных бизнес-аналитиков и продактов.

А для задач сбора требований и проектирования программных систем книга практически ничего не дает.

Глядя на разрастание объема требований в очередном проекте, вспомнил шутку про поправочный коэффициент π×e, на который нужно умножать число выявленных требований, чтобы получить число реальных.

Эта формула имеет геометрический смысл: R×π×e,

где R - число требований, число π в этой показывает круг, который нужно пройти для каждого согласования, а число e - скорость, с которой заказчики придумывают новые требования.

При многоступенчатом процессе согласования уже нужно брать интеграл по поверхности требований, но итоговая формула получается тоже простой: 2π×R×h×e, где h - число уровней согласования.

В среднем получается ~8.54, что очень похоже на большинство проектов.

Математики до сих пор не уверены, является ли это число иррациональным, но мы-то знаем...

Обратите внимание, что π в данном случае показывает разворот требований на 180°, то есть строго в противоположную сторону. Если ваш заказчик при согласовании требует не противоположного, а перпендикулярного первоначальной задумке, можно использовать коэффициент π/2, то есть примерно 4.27.

Правда, если заказчик движется не по окружности, а по синусоиде, придется опять вернуться к 8.54, т.к. заказчик колеблется от π/2 до -π/2, что дает полный размах безумия.

Так же в терминах управления проектами интерпретируется знаменитое равенство Эйлера:

e^iπ + 1 = 0.

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

Сел тут выписывать категории стейкхолдеров. В проекте положено делать анализ стейкхолдеров, да? Обычно его либо не делают, либо с умным видом рассказывают про "луковичную диаграмму" (и иногда даже рисуют её).

Луковичная диаграмма делит стейкхолдеров на круги, или слои. Конкретные названия слоев варьируются.

Йэн Александер (собственно, автор методики и книг «Writing Better Requirements» и «Discovering Requirements: How to Specify Products and Services» — кстати, не вижу, чтобы они переводились на русский, а это вам не Вигерс, это конкретное руководство про выявлению и написанию требований) предлагает следующие:

0 слой: сам продукт
1 слой: "наша" система: продукт + операторы + инструкции/правила по работе с системой
2 слой: объемлющая (содержащая) система: наша система + бенефициары нашей системы (кто получает пользу от её функционирования, но сами могут не пользоваться ей)
3 слой: широкое окружение: объемлющая система + все остальные стейкхолдеры

Раскладывает стейкхолдеров по типам так:
1 слой ("наша система"):

* Нормальный оператор: вводит данные, отдает команды и получает результат от работы продукта. Главные требования: наличие необходимых функций, удобный и понятный пользовательский интерфейс, скорость работы, отсутствие ошибок/потерь данных, безопасность.

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

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

2 слой ("содержащая система"):

* Функциональный бенефициар. Получает пользу от нашей системы, возможно не напрямую, а от операторов. Это немного старомодное деление, когда умение работать с компьютерами было отдельным скиллом. Хотя встречается и сейчас, в любом взаимодействии, когда вы смотрите на экран компьютера с обратной стороны: на кассах, в банках, МФЦ и т.п. Функциональный бенефициар в данном случае мы, мы взаимодействуем с оператором, а не с системой напрямую.

* Владелец смежной системы. Александер называет их "Ответственными за интерфейсы". С кем вы будете говорить, когда речь пойдет об интеграциях.
* Приобретатель. Может быть один (в организации) или миллионы (в массовом продукте, тогда их представляет Продакт). Кто выкладывает денежки. Кто отвечает за то, чтобы продукт был сделан.
* Спонсор или чемпион продукта. По-русски мы так не говорим, но это тот, кто вообще пробивает создание нашего продукта. Причем не только находит деньги но и решает политические вопросы. Исполнительный продюсер.

3 слой ("широкое окружение"):
* Негативный стейкхолдер. Тот, кто может пострадать от внедрения системы: физически, финансово или иным способом, за который вы будете отвечать перед регуляторами или судом. Требования регуляторов на самом деле — формализованные и обобщенные требования негативных стейкхолдеров (или ограничения). Александер добавляет сюда же стейкхолдеров, которые могут пытаться вредить работе продукта.

Он даже предлагает выделять специальную роль:

* Враждебный агент. Те, кто совершенно точно станут активно вредить или использовать продукт не по назначению. С определенным уровнем хитрости и креативности. Например, вопросы для любого открытого продукта с хостингом пользовательского видео: как вы будете бороться с порно-контентом, а для продуктов с комментариями или отзывами: как бороться с размещением спамерских ссылок.

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

* Финансовый бенефициар. Получит прибыль от создания системы. По-честному, редко берется в расчет, если вы не делаете коммерческий продукт.

* Регулятор. Тот, кто задает правила игры — обычно в виде ограничений или навязанных функций.
* Разработчик. Есть мнение, что они вообще не должны быть в этой модели, они перпендикулярны.
* Консультант (западная практика, бывает ли в РФ?)
* Поставщик (обычно очень далекая роль, но для некоторых систем бывает крайне важен)

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