Как неправильно понять первый подраздел про «требований теперь нет»

Есть много способов ошибиться в понимании представленного материала: достаточно поглядеть на какой-то свой текущий проект и сказать «а вот у меня не так». Да, скорее всего не так — в каком месте пелотона в части методов инженерной работы находится ваш проект? А проекты, которые вы до этого наблюдали? И ошибка начинается с определения самого «проекта» как разового мероприятия: «я вам дал рецепт, приготовьте по нему пирожок в обмен на деньги, и до свидания». Ошибочное утверждение начинается с того, что обсуждается неявный «водопад»: «заказчик чего-то захотел, описали это в требованиях, сделали эскизный проект, рабочий проект, изготовили систему, затем испытали — и подписываем акт, жизненный цикл может опционально ещё включать эксплуатацию с техобслуживанием и ремонтами, но это отдельно будем договариваться, когда-нибудь потом». Современный взгляд на проект даёт совершенно другие границы: эволюционная разработка сначала выдаёт MVP, а затем множество дополнительных отдельных фич, которые тоже проходят через свои MVP, ввод в эксплуатацию новых версий системы непрерывный, а для этого — «непрерывное всё», разработка не заканчивается. Нет никаких «захотел — зафиксировали (даже не задокументировали, именно зафиксировали в неизменной форме) — разработали — отдали — конец».

Неверное рассуждение начинается прямо с «заказчик чего-то захотел». Дело в том, что «заказчик» чего-то хочет многократно, разного и всё время проекта, даже после того, как пошла эксплуатация системы. При этом часто он ничего не «хочет», но меняется жизнь, меняется сама организация проекта, появляются «хотелки» других внешних проектных ролей, проблемы приходят от клиентов заказчика, а не его самого (скажем, сто тысяч клиентов приходят не равномерно три месяца, а появляются все в последний день квартала — и это может быть неожиданно для самого заказчика, но разработчики должны бы такое учесть, даже если их об этом не просили, иначе перегруженная система работать не будет, а разработчик получит деньги за по факту не выполненную работу, ибо «что попросили, то и сделали»). Нет, требования устаревают на второй день, поправки к ним второго дня — на третий, а «хотелка» четвёртого дня звучит «а давайте попробуем ещё вот так — вдруг будет лучше?», то есть «делаем, но не факт, что оставим так — уйдёт на A|B тест». Система (даже мыслимая в будущем, ещё не сделанная) и её окружение (даже то, которое ожидается в будущем) меняются непрерывно (хотя бы в представлениях всех участников проекта и внешних проектных ролей), и разработка системы обязана это учитывать. Статичные «утверждённые требования» тут — привет от неработающего «водопада», однократного прохождения жизненного цикла.

И дело не в том, что нужно разово привлечь какого-то специалиста из предметной области заказчика для разработки требований, далее выработки всего набора концепций, и так далее до конца проекта. Нет, ставится вопрос не о «привлечении к разработке», а вопрос «обеспечения понимания предметной области разработчиками», ибо это понимание не на однократное выполнение заказа, а понимание на какой-то долгий непрерывный поток всё новых и новых изменений системы, и эти изменения приходится делать и из-за предложений (не пишем «требования», ибо это могут быть предложения сделать какую-то пробу для A|B теста, или предложения провести какой-то другой эксперимент) заказчика или даже клиентов заказчика, или из-за изменившегося окружения (никто ничего не захотел нового, но жизнь изменилась: новые стандарты подключения к внешним подсистемам, новые форматы данных, новые часы работы внешних сервисов, новые расходные материалы, новые погодные условия и т.д.).

Поэтому акцент в системной инженерии сейчас делается не на разовое привлечение прикладного специалиста (предметника/«business domain expert»/«subject matter expert») для разработки «начальных требований», а на понимание предметной области/business domain командами разработчиков, визионером, архитектором.

Ещё один источник непонимания — это то, что для какой-то системы существуют множество предметных областей её функциональности. Для закрытия каждой подобласти будут образованы отдельные команды, и архитектор нарежет систему на отдельные модули с по возможности минимальной связностью/зацеплением и максимальной сплочённостью так, чтобы минимизировать взаимодействие этих команд. Это означает, что каждая команда будет иметь свой ритм выпуска фич — но целостность системы будет как-то сохраняться. Это означает, что у каждой команды в случае «разработки требований» должны были бы быть собственные «подтребования», которые ещё и непрерывно изменяются, и не имеют деонтического («долженствования») статуса, а имеют доксический («верю, что будет вот так») статус гипотез.

Для команд поддержки предметных подобластей (domains, bounded contexts) тем самым важно понимание ими этих предметных областей, а не «понимание спецификации требований». Описание системы этими командами (как описание чёрного ящика, так и описание прозрачного ящика) делается другими документами, при этом сегодня это будут исполнимые в форме тестов (то есть формальные) описания, разработка будет идти test-first. Сначала отвечаем на вопрос «как мы узнаем, что система работает, и делает это хорошо?». Никаких требований, другие формы описания функциональности, интерфейсов, и жёсткое управление конфигурацией, ибо у разных команд будут быстро меняющиеся разные системные описания. Конечно, команды сотрудничают в том, чтобы система оставалась целостной.

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

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

Новое понимание разработки — это не разовая разработка конечного варианта системы, который «сдают заказчику». Это совсем другое, это «эволюция системы умными мутациями в ходе долгого проекта». В биологической эволюции предыдущие версии биологических систем гибнут, чтобы с ними погиб неудачный геном, а в техноэволюции геном лежит себе в репозитории, и мутация делается без сопутствующих смертей системы, ведь могут заменяться только техно-части. У крабика может потихоньку расти клешня «как у вида», но это будут множество особей — популяция. А у системы-технокрабика просто будут менять одну клешню на другую без смерти всей системы, а мемом системы (описание системы) будет храниться рядом, и неважно даже, популяция из одного технокрабика, или из множества. Если клешня техно-системы неудачна, то команда клешни будет её менять, пока та не станет удачной. Если мир поменялся (динамический ландшафт приспособленности), и только что удачная клешня стала неудачной — её опять поменяют, да ещё и попробуют пять разных вариантов один другого лучше. Другая команда будет делать то же самое для ног крабика, глаз и т.д. — в биологии это будут мутации генов и много-много смертей отдельных крабов, большие популяции крабов, чтобы попробовать много вариантов с мутациями, много времени. Для технокрабика это будет 10 вариантов в день (и это смарт-мутации, большинство заведомо плохих вариантов будут откинуты в ходе компьютерного моделирования — это мы считаем только то, что введено в эксплуатацию), в каждом варианте будет изменено немного фич, система будет оставаться целой кроме изменяемых частей. И нет «требований к крабику», всё ж постоянно изменяется, это просто техноэволюция. Для понимания нужно третье поколение системного мышления, выход за один жизненный цикл.

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

Для прототипов космического корабля Starship фирмы SpaceX иногда разработчики меняют своё мнение так быстро, что даже не успевают испытать свежеизготовленный прототип, и его тогда разбирают на запчасти, если нельзя просто быстро модифицировать целый корабль. Каждый прототип делается отличным от предыдущего, а в конечном итоге планируется выпускать один космический корабль раз в три дня, и это гарантированно будут не абсолютно одинаковые космические корабли. Пассажирские самолёты Boeing и сейчас выпускаются каждый в своей уникальной конфигурации, но мы тут говорим даже не о том, что в разработке продуктовая линия со множеством модификаций одного продукта, а о том, что по мере выпуска продукт всё время обновляется и единицей рассмотрения для разработчиков является не только какое-то изменение (инкремент, фича) с его жизненным циклом от понимания нужности до эксплуатации в составе целой системы, но и сама жизнь системы, которая разрабатывается-эксплуатируется одновременно (что и отражалось в названии метода DevOps — от development и operations, этот метод и последовавшая за ним инженерия платформы разработки будут рассмотрены в нашем руководстве позже).

Тем самым неверно рассуждать для ситуации «единичного требования» в «одном цикле разработки». Нужно сразу понимать, что это ситуация техноэволюции, смотреть контекст/окружение происходящего с описанием системы в ходе непрерывной разработки, непрерывного изготовления, непрерывной сборки, непрерывного разворачивания, непрерывного ввода в эксплуатацию, проходящих с системой в ходе её развития/evolving (будем переводить evolving system как «развивающаяся система»).

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

• Ошибочно считать, что это описание в деонтической (долженствования), а не доксической (предположение, вера) модальности. Нет, это не «требования», а «гипотеза». Нельзя говорить «вы должны, ах нет, уже не должны, но нет, мы опять поменяли, что вы должны — вы должны, но уже другое». Перестали говорить «X должен быть 10», но «я сейчас верю, что X будет 10, а завтра посмотрим, давайте проверим догадку/гипотезу».
• Ошибочно считать, что это не альфа «описание», а привычный рабочий продукт «спецификация требований» — и далее, как обычно, подтягивается вся традиционная идеология водопада, где «изменение спецификации требований — это долго, дорого, плохо», «сначала увяжите все требования между собой, а потом мы их проверим все вместе».
• Сплошь и рядом «требования» — это описание системы в языке разработчиков (не «игрок должен быть зарегистрирован за три минуты», а «данные пользователя должны быть получены с интерфейса за три минуты»), нет описания в духе движения customer eXperience. Такие описания, как сценарии использования, не так чтобы гарантируют, что описания будут в предметном языке, но позволяют ещё и ещё раз обратить на это внимание и уж точно описать функциональность, а не только конструктивность. И тут ещё одна подвижка: попытка «интерфейсы» (конструктивное описание) заменить словом «контракты», в котором упор опять-таки делается на функциональность (взгляд от надсистемы на систему с точки зрения того, «зачем это всё», а не «что во что втыкается»).
• «Спецификации требований» (а не спецификации системы!) сегодня представляют собой документы со смесью описаний функциональности, архитектурных характеристик, архитектурных решений и всего чего угодно. Нет «требований», значит нет «спецификации требований» и можно отдельно говорить обо всех этих разных видах описаний, разных видах спецификаций. В частности, можно проконтролировать, чтобы описание (спецификация, причём как гипотеза) было именно описанием желаемого поведения системы, а не просто описанием конструкции системы в статике. Для этого и «сценарии», хорошо подходящие для описания поведения. Подойдут use cases, сценарии (use case текстом), storyboards (картинки заставляют сделать grounding в физический мир) и т.д.: всё, где есть поведение. Всякие языки для BDD (ATDD и похожих методов) пишутся как business rules (в том числе Gherkin) и они тут вообще предпочтительны, хотя без картинок, зато с возможностью проверки.
• Архитектурные характеристики попадали в состав требований как какие-нибудь «нефункциональные требования» или «требования качества». Сейчас они обсуждаются отдельно от функциональных характеристик, с ними работают через метрики, а значения тоже проверяются автоматизированным архитектурным тестированием с помощью особых тестов — fit functions. По их поводам выпускаются архитектурные решения, и они тоже предмет непрерывных изменений в ходе проекта, а выявляют их архитекторы, а не разработчики фич.
• Если оставить «требования» и они будут поняты как документ «спецификация требований», возникает соблазн посадить ещё «прокладку» между специалистами предметной области и разработчиками из инженеров по требованиям. Возникает проблема испорченного телефона, она же проблема многократного перевода. Информация в ходе её передачи от внешних проектных ролей разработчикам и архитекторам не только будет потеряна, она ещё и будет существенно искажена.

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

И ещё нужно понимать, что «просто требования» не бывают сами по себе, они ведь могут быть нереализуемы, и это нужно отслеживать. Например, требования «конверсия должна прирасти на 20% от текущего уровня» маловато будет, нужна какая-то идея, с чего бы она там будет прирастать — и это уже сразу не «требования». Не ввязываемся в проект, если не удалось быстро (скажем, за три дня) найти идею/изобретение/концепцию для «фичи» системы (вряд ли можно запланировать изобретение, скажем изобрести микроволновку или компьютер во времена Бэббиджа). Это подробней обсуждается в стратегировании как практике выбора направлений развития/evolving для систем. Стратегии всё чаще и чаще не формулируются в форме «требований к предприятию», но в виде документирования методов работы — сценариев (планы, функциональные описания) или архитектурных решений (policy, за соблюдением которых прислеживают — когда речь идёт об архитектурных характеристиках личности, организации, сообщества). Хотя тут, конечно, речь не идёт о формальной записи, соответствие которой легко протестировать.