TL;DR: Когда проблема, данные и ответственность уже определены, на столе всё равно могут остаться несколько архитектурно допустимых вариантов. Выбор между ними — не технический спор, а управленческий компромисс. Разберём, как сравнивать варианты по стоимости реализации и владения, обратимости и остаточному риску, почему скоринг в Excel иногда только маскирует выбор и в какой момент ИТ должно остановить преждевременный старт, чтобы проект сам не создал стоимость выхода.
В предыдущей статье мы разбирались с корпоративной «правдой» в данных: кто вправе определить, какое значение считать правильным, если разные системы и функции дают разные ответы. Вывод там был принципиальным: система сама по себе не становится источником истины. Сначала компания определяет правило, ответственность и полномочия, и только затем технология это решение реализует.
Но даже когда проблема, ценность, ответственность, процесс и данные достаточно определены, следующего шага автоматически не возникает. Вместо одного очевидного способа реализации на столе могут остаться несколько вполне работоспособных вариантов. Каждый что‑то даёт, каждый чего‑то стоит, и каждый оставляет компании собственный набор будущих проблем.
На одном из проектов мы дошли именно до такой развилки.
Новая ERP должна была работать с данными, которые до этого жили примерно в десятке разных систем и массивов. После разбора источников и правил НСИ осталось три реальных варианта: сохранить распределённые источники и интегрировать их с ERP; вести значительную часть валидации НСИ внутри ERP, во многом вручную; либо выделить отдельный корпоративный контур НСИ.
Все три варианта можно было реализовать. Именно поэтому выбирать стало сложнее.
Когда архитектура уже не может выбрать за компанию
До управляющего комитета варианты прошли архитектурный комитет и несколько внутренних совещаний. Я собрал их плюсы и минусы в презентацию.
Пока обсуждение касалось количества интеграций, сложности сопровождения и места реализации правил НСИ, вопрос ещё можно было считать преимущественно архитектурным. Но у третьего варианта обнаружилось последствие совсем другого порядка.
Отдельный контур НСИ требовал не только внедрить ещё одну систему. Нужно было создать небольшую постоянную функцию — руководителя и несколько специалистов, которым предстояло заниматься корпоративной НСИ уже после окончания проекта. Здесь архитектурная картинка впервые получила вполне осязаемую цену.
До этого мы обсуждали интерфейсы, источники, валидацию, масштабируемость. Теперь разговор упирался в людей, новую ответственность и дополнительный бюджет. Не огромный департамент, но всё равно новая организационная единица, которую нужно создать, укомплектовать и содержать.
На управляющем комитете это уже нельзя было спрятать за формулировкой «выделить отдельный контур НСИ». Сам факт появления дополнительного бюджета менял характер разговора. При этом все понимали и обратную сторону: затраты возникали в одном месте, а результатом должны были пользоваться сразу несколько функций — бухгалтерия, финансы, производство, закупки, продажи.
Именно поэтому вопрос оказался на управляющем комитете. Решалась уже не архитектура системы, а готовность компании заплатить организационную цену за выбранную модель работы с НСИ.
На этом же фоне продолжался спор с производством. Представитель производства в проекте отстаивал производственную систему как наиболее надёжный источник, и было бы слишком просто списать его позицию на функциональный эгоизм.
Для производства качество входящих данных — не вопрос красоты справочника. Ошибка в характеристиках или количестве материала доходит до реального производственного процесса, а последствия потом приходится разгребать именно тем, кто отвечает за выпуск продукции. Поэтому стремление контролировать данные, от которых зависит работа производства, совершенно рационально.
По выходной продукции позиция была ещё сильнее: именно в производственном контуре соответствующая информация естественным образом возникала. По входящим материалам аргумент расширялся — производство является конечным пользователем, следовательно, его данные должны быть наиболее точными.
То есть спор шёл не между «правильной корпоративной архитектурой» и «упрямым производством». Сталкивались две легитимные потребности. Производству нужна операционная достоверность там, где ошибка бьёт по его результату. Компании в целом — согласованное представление объекта, которым одновременно пользуются разные функции.
Локальную достоверность производства нужно было сохранить. Но из неё ещё не следовало, что именно производственная система должна стать местом реализации корпоративных правил НСИ для всех остальных.
С вариантами реализации происходило то же самое. Интеграционная схема сохраняла много связей, дорогую поддержку и проблему масштабирования. Валидация внутри ERP помещала специализированную функцию в большую и тяжёлую систему. Отдельный контур НСИ выглядел профессиональнее и лучше масштабировался, но требовал организационных изменений и денег.
В этот момент вопрос перестал звучать как «какая архитектура правильная?».
Компания должна была решить, с последствиями какого варианта она готова жить.
Лучшего варианта может не быть
У технических экспертов есть вполне определённая функция. Архитектор должен убрать технически неприемлемые варианты и показать ограничения и зависимости. Аналитик — проверить соответствие процессам и данным. Интегратор — оценить сложность реализации и сопровождения.
Но результатом хорошей экспертизы не обязательно становится единственный вариант. Иногда её результат — два или три решения, каждое из которых допустимо, но оптимизирует разные вещи.
Именно здесь появляется соблазн снова попросить экспертов: «Хорошо, но всё‑таки скажите, как правильно».
Проблема в том, что ответ уже вышел за пределы одной экспертизы. Архитектор способен обосновать, какой вариант технологически чище. Он не может своим профессиональным авторитетом решить за компанию, готова ли она создать новую организационную функцию и выделить на неё бюджет. Финансы могут оценить стоимость, но не определить архитектурную допустимость. Производство отлично знает свою часть данных, но его локальная рациональность не заменяет корпоративного решения.
Обратная крайность — «бизнес решил, ИТ пусть реализует» — ничем не лучше. Если участникам не показали технические последствия, стоимость дальнейшего владения, ограничения и цену изменения решения, бизнес выбирает не между реальными альтернативами, а между их короткими описаниями.
Один вариант может быть дешевле на старте, но дороже в сопровождении. Другой быстрее запускается, но глубже встраивается в существующую архитектуру. Третий требует организационного изменения, зато позволяет убрать часть постоянно воспроизводящихся конфликтов.
Эксперты могут сократить пространство выбора и дать рекомендацию. Но в конце всё равно остаётся момент, когда полномочный уровень должен сказать: мы понимаем цену этого варианта и принимаем её.
Матрица вариантов и последствий
Когда вариантов несколько, спор хочется превратить в расчёт: составить критерии, назначить веса, поставить баллы, перемножить и получить победителя с убедительной точностью до десятых.
Иногда scoring model действительно полезна. Если критерии измеримы, оценки сопоставимы, а веса заранее отражают согласованные приоритеты, она помогает структурировать выбор. Но в управленческих развилках математика легко начинает изображать объективность там, где её нет.
Какой коэффициент поставить напротив создания нового подразделения? Насколько семь баллов по масштабируемости компенсируют организационные изменения? Кто решил, что стоимость важнее обратимости именно в полтора раза?
Поэтому я бы начинал не с вычисления победителя, а с матрицы вариантов и последствий.
Её цель — привести участников к состоянию, в котором они одинаково понимают реальные альтернативы, цену каждого варианта и тот компромисс, который должен быть принят полномочным уровнем. Если после заполнения таблицы люди всё ещё спорят о том, что означает сам вариант или какие последствия он создаёт, матрица свою задачу не выполнила.
В простом случае достаточно такого набора вопросов:
Что сравниваем | Какой вопрос задаём |
|---|---|
Бизнес‑эффект | Что этот вариант позволяет получить и что ограничивает? |
Стоимость реализации | Во что обойдётся получение решения? |
Стоимость владения | Во что обойдётся дальнейшая жизнь с ним? |
Срок | Как вариант влияет на момент получения результата? |
Сложность | Какие новые связи, процессы, роли или точки отказа появляются? |
Организационные последствия | Нужно ли менять ответственность, создавать функцию, выделять людей? |
Масштабируемость | Что произойдёт при росте объёма, числа систем, пользователей или объектов? |
Обратимость | Насколько трудно и дорого будет изменить решение позже? |
Остаточный риск | Какие существенные проблемы останутся даже после качественной реализации? |
Управленческий компромисс | Что руководство должно сознательно принять вместе с вариантом? |
Этот список не универсален. Для одного проекта критичен срок, для другого — стоимость владения, для третьего — регуляторные ограничения. Важен не стандартный набор строк, а договорённость о том, по каким признакам компания действительно различает варианты.
При этом матрица не создаёт в серии ещё один независимый реестр. Она готовит содержательную часть решения: варианты, их цену и последствия. После выбора существенное решение можно зафиксировать в Карте решений из третьей статьи — уже с владельцем, сроком и принятым вариантом. Если выбор меняет корпоративное правило данных, результат затем отражается в Карте источников и ответственности за данные из пятой статьи, где хранится действующее правило и его связь с решением.
Инструменты здесь работают цепочкой, а не конкурируют друг с другом.
Цена начинается там, где заканчивается бюджет проекта
Стоимость автоматизации удобно считать в лицензиях, разработке, внедрении и инфраструктуре. Но значительная часть последствий проявляется уже после того, как проектная команда разошлась.
В нашем кейсе отдельный контур НСИ требовал не только реализовать систему. Нужно было создать организационную единицу и обеспечить её людьми. У множества интеграций цена распределялась иначе: очередную связь можно сделать сравнительно быстро, но растущую сеть связей приходится сопровождать, изменять и диагностировать.
Для разговора с руководством это удобно рассматривать как две экономики решения: стоимость входа и стоимость дальнейшего владения. Условно — CAPEX и OPEX, хотя в конкретной компании бухгалтерская классификация затрат может быть другой.
В нашем выборе эта разница была принципиальной. Множество интеграций не требовало создания новой организационной функции, но каждая новая связь увеличивала будущую стоимость сопровождения и диагностики всей конструкции. Валидация внутри ERP использовала уже существующий крупный контур, но оставляла внутри него специализированную функцию и значительный объём ручной работы. Отдельный НСИ требовал вложиться в самостоятельный контур и организационную функцию, зато стоимость дальнейшей жизни решения становилась более явной и управляемой.
Поэтому «сколько стоит вариант?» для меня состоит минимум из двух вопросов:
сколько стоит получить решение — и сколько стоит потом с ним жить?
Вариант, который дешевле довести до запуска, вполне может оказаться дороже на горизонте нескольких лет.
Но даже этого мало. В том проекте мы не формализовали ещё одну вещь, хотя она присутствовала в обсуждениях, — цену отказа от уже сделанного выбора.
Сколько будет стоить передумать
Решение принимается сегодня, а жить с ним предстоит в условиях, которых сегодня ещё нет. Изменится объём бизнеса, появятся новые системы, перестроится организация, поменяется стратегия. Поэтому я сейчас обязательно добавил бы к сравнению вопрос об обратимости:
если через два года мы поймём, что этот путь больше не подходит, что придётся переделать?
Мы тогда обсуждали такие последствия, но не выделяли обратимость в отдельный критерий и тем более не скоринговали её. Ретроспективно это кажется важным упущением: два одинаково работоспособных сегодня варианта могут очень сильно различаться по цене завтрашнего отказа.
Систему можно заменить. Функцию — уже сложнее
В нашем кейсе у обратимости был ещё один слой, который я сегодня обязательно вынес бы на обсуждение отдельно.
Выбирая отдельный контур НСИ, компания создавала не только технический компонент. Она создавала организационную функцию. После этого у функции появляются люди, руководитель, ответственность, процессы, бюджет, отношения с другими подразделениями. Даже если через несколько лет заменить саму MDM‑систему, вопрос о том, кто управляет корпоративной НСИ, уже никуда не исчезнет.
Техническую платформу можно мигрировать. Интерфейсы можно переписать. Схему интеграций — перестроить. Это может быть очень дорого, но объект изменения понятен.
С организационной функцией всё иначе. Как только компания явно передала кому‑то ответственность за корпоративную НСИ, обратный переход к состоянию «пусть каждая система разбирается сама» становится не просто технической миграцией. Нужно снова менять полномочия и распределять ответственность между функциями.
Поэтому строка «организационные последствия» в матрице не должна быть примечанием к архитектуре.
Иногда именно там находится самая труднообратимая часть решения.
С рисками история ещё хуже
Общего «высокий — средний — низкий» для выбора недостаточно. Гораздо полезнее спросить: какая существенная проблема останется, даже если этот вариант будет реализован хорошо?
Это и есть тот остаточный риск, который компания фактически принимает вместе с решением.
Один вариант может оставить большой объём ручной работы. Другой — сложную интеграционную схему. Третий — зависимость от организационной функции, которую ещё нужно обеспечить людьми.
В нашем кейсе остаточные риски тоже обсуждались, но отдельной формализованной оценки не было. Поэтому ниже нет попытки восстановить несуществующую историческую оценку. Это ретроспективный взгляд на то, какие вопросы я задал бы сегодня.
Как я оформил бы тот выбор сейчас
Если собрать обсуждение того проекта в одну матрицу уже с сегодняшним опытом, она выглядела бы примерно так:
Критерий | Множество интеграций | Валидация НСИ в ERP | Отдельный контур НСИ |
|---|---|---|---|
Основная идея | Сохранить распределённые источники и связать их с ERP | Вести значительную часть валидации внутри ERP, во многом вручную | Выделить специализированный корпоративный контур НСИ |
Сопровождение | Большое количество связей и высокая стоимость сопровождения | Специализированная функция внутри большой и тяжёлой ERP | Одна специализированная система проще в обслуживании |
Реализация корпоративных правил НСИ | Остаётся распределённой между источниками и интеграциями | Значительная часть переносится внутрь ERP | Выделяется отдельный корпоративный контур |
Стоимость реализации | Реализация и развитие множества интеграций | Доработка существующей ERP под дополнительную функцию | Создание и внедрение отдельного контура |
Стоимость владения | Сопровождение растущего количества связей | Сопровождение функции внутри ERP плюс ручная валидация | Сопровождение специализированной системы и отдельной организационной функции |
Масштабирование | Сложность растёт вместе с количеством связей | Функция продолжает расширяться внутри ERP | Масштабируемость была одним из аргументов в пользу варианта |
Организационные последствия | Новая отдельная функция не требовалась | Новая отдельная функция не требовалась | Требуются отдельная организационная единица, руководитель, люди и дополнительный бюджет |
Обратимость — ретроспективно | Чем больше интеграций построено, тем больше связей потребуется изменить при переходе к другой модели | Вынос функции из ERP потребует отделить накопленную в ней логику и изменить связанные процессы | При смене технического решения потребуется переносить НСИ и переподключать потребителей; сама функция управления НСИ при этом никуда не исчезает |
Остаточный риск — ретроспективно | Даже при качественных интеграциях остаются распределённость источников и стоимость сопровождения | Даже при качественной реализации остаются ручная валидация и размещение специализированной функции внутри тяжёлой ERP | Отдельный контур нужно обеспечить компетентной командой; уже после выбора именно поиск людей оказался практической проблемой |
Что должно быть принято руководством | Сложность и стоимость распределённой схемы | Размещение специализированной функции и значительной ручной работы внутри ERP | Создание отдельной функции и связанные с этим организационные последствия |
Исторически мы не заполняли эту таблицу и не скоринговали обратимость или остаточный риск. Тогда были архитектурный комитет, внутренние обсуждения и презентация с плюсами и минусами. Таблица выше — ретроспективная реконструкция того, как я структурировал бы этот выбор сегодня.
Для меня в ней принципиальна последняя строка. В обычной сравнительной таблице там хочется увидеть «итоговый рейтинг». Здесь полезнее другой вопрос:
Что именно руководство должно принять вместе с этим вариантом?
Фраза «отдельный контур НСИ лучше масштабируется» ещё не завершает выбор. Его завершает другая формулировка: если выбираем этот путь, компания создаёт отдельную организационную функцию, назначает руководителя и выделяет дополнительный бюджет.
После этого решение становится менее комфортным — и гораздо более настоящим.
Эксперт тоже находится внутри системы интересов
Есть удобная картина мира, в которой бизнес заинтересован в результате, ИТ — в архитектуре, а подрядчик со стороны просто профессионально рекомендует лучший вариант. Реальный проект устроен сложнее: у каждой стороны есть собственная рациональность и собственные стимулы.
В нашем случае это особенно хорошо было видно на варианте с ERP. Если бы значительную часть валидации НСИ оставили внутри неё, для нас как интегратора это означало продолжение работ в том же проекте: дополнительный объём нужно было бы спроектировать, реализовать и внедрить, и заказчик заплатил бы за эту работу.
Это не делало вариант плохим и не превращало любую рекомендацию интегратора в недобросовестную. Но коммерческий интерес существовал, а значит, особенно важно было не смешивать право рекомендовать с правом окончательно выбрать.
Сильный эксперт обязан иметь позицию. Архитектор, который на любой вопрос отвечает «решайте сами», не выполняет свою работу. Интегратор тоже должен сказать, какой вариант считает предпочтительным и почему. Но после профессиональной рекомендации не должно незаметно появляться «значит, так и делаем».
Архитектор способен оценить сложность связей, интегратор — трудоёмкость реализации, эксперт по данным — последствия для НСИ. Ни один из них не может самостоятельно решить, что компания готова создать новую организационную единицу и выделить дополнительный бюджет.
У бизнеса есть симметричная ловушка. Фраза «вы специалисты, вам и выбирать» выглядит как уважение к экспертизе, но легко становится переносом ответственности. Пока всё работает, это «решение профессионалов». Когда проявляется его цена — «ИТ так выбрало».
ИТ отвечает зеркально: «мы предупреждали». Но предупреждение, разбросанное по презентациям, протоколам и устным обсуждениям, ещё не означает, что компания действительно приняла единый набор последствий.
В нашем проекте окончательное решение приняли совместно несколько функциональных директоров. Для меня в этой истории важен не только выбранный вариант, но и то, кто не выбрал его вместо компании: не производство, не архитектура и не интегратор, которому одна из альтернатив могла быть коммерчески выгоднее.
Экспертиза сузила пространство выбора. Корпоративный компромисс остался у тех, кому предстояло отвечать за его последствия.
Как полезная таблица постепенно превращается в алиби
Матрица начинает деградировать ещё до того, как становится большой и бюрократической. Первый симптом — решение уже существует, а критерии появляются после него. Под любимый вариант особенно хорошо подходит масштабируемость, неудобному внезапно начинают считать стоимость, а слабое место фаворита объявляют второстепенным.
Дальше возникает желание придать этому объективный вид. Появляются веса, баллы и итоговые 84,7 против 79,3. В самих числах нет ничего плохого, но если никто не может содержательно объяснить, почему организационное изменение получило четыре балла, а обратимость весит ровно 15 процентов, математика не уменьшает субъективность — она её маскирует. Так инструмент выбора превращается в инструмент доказательства заранее выбранного ответа.
Следующая стадия деградации — иллюзия дешевизны. Матрица тщательно считает то, что попадает в бюджет проекта, и почти не замечает жизнь после него. Срок внедрения, лицензии и разработку оценить проще, чем годы сопровождения, будущие интеграции, организационную функцию или цену последующего отказа от решения.
Особенно удобно спрятать организационные изменения за техническими словами. «Выделить сервис», «централизовать функцию», «создать отдельный контур», «перенести контроль в систему» звучат как решения на архитектурной схеме. Но за ними могут стоять новые роли, полномочия, люди и бюджет. Если матрица этого не показывает, компания выбирает только техническую половину варианта.
Последняя стадия — снятие ответственности. Сначала таблица помогает увидеть последствия, потом кто‑то произносит: «По матрице победил вариант Б». Как будто ответственность теперь лежит на Excel.
Ещё хуже, когда каждый участник оставляет в документе своё предупреждение: архитектура написала про риск, финансы — про цену, бизнес — про срок, подрядчик — про предварительность оценки. Все застраховались, но никто так и не принял общий компромисс.
Это уже знакомая по Карте решений проблема: инструмент, созданный для действия, превращается в доказательство будущей невиновности.
Хорошая матрица заканчивает спор не тогда, когда заполнены все клетки, а когда понятно, какие варианты допустимы, чем каждый обойдётся компании, что останется после реализации, кто рекомендует и кто принимает последствия.
Без последнего пункта перед нами не решение, а аккуратно оформленная неопределённость.
Когда ИТ вправе сказать «пока нет»
Из всего этого легко сделать слишком простой вывод: раз корпоративный компромисс принимает бизнес, ИТ после управленческого решения остаётся только выполнить его. Здесь важно слово «допустимый».
Если вариант нарушает обязательные архитектурные ограничения, требования безопасности или технически не способен дать требуемый результат, ИТ не обязано изображать его равноправной альтернативой. Экспертиза должна отсеять такой путь и объяснить причину.
Другое дело — вариант технически возможен, но неприятен ИТ. Он может создавать технический долг, быть хуже с точки зрения целевой архитектуры или требовать временного решения. Если последствия понятны, обязательные ограничения соблюдены, а полномочный уровень сознательно выбирает этот путь ради срока, стоимости или другого бизнес‑эффекта, фразы «архитектуре не нравится» недостаточно для вето. Иначе техническая экспертиза незаметно получает право принимать бизнес‑решения.
Но есть момент, когда остановка снова становится оправданной:
Мы не должны превращать один из вариантов в свершившийся факт, пока полномочный уровень не принял его последствия.
«Давайте пока начнём с варианта Б, а на комитете потом определимся». «Архитектура рекомендует А — считайте, что согласовано». «Бюджет уже защищён, поздно обсуждать альтернативы».
Проблема здесь не в процедуре согласования. Реализация сама начинает принимать решение за организацию. Разработчики создают структуры данных, интеграторы строят связи, закупаются лицензии, проектируются процессы. Чем дальше продвигается работа, тем дороже становится отказ от выбранного направления.
Формально вариант ещё можно поменять. Фактически проект уже создал стоимость выхода.
Под стоимостью выхода я здесь имею в виду всё, что придётся потерять или переделать, если компания позднее откажется от фактически начатого направления: уже реализованную логику, интеграции, лицензии, данные, процессы, сроки.
И здесь у бизнеса возникает совершенно справедливое возражение: проектная команда тоже стоит денег. Если для управленческого решения нужно собрать комитет, это не означает, что двадцать человек должны неделю смотреть в потолок и ждать протокола.
Отлагательное вето не равно остановке всего проекта.
Останавливать нужно ту работу, которая предрешает спорный выбор. Пока решение принимается, команда может продолжать то, что останется полезным при любом из допустимых вариантов: уточнять требования и бизнес‑правила, разбирать и очищать данные, готовить сценарии тестирования и миграции, работать со средами, закрывать независимые технические задачи.
Смысл паузы не в том, чтобы прекратить расходовать деньги. Смысл в том, чтобы не заливать бетоном несущий архитектурный каркас, пока компания ещё не решила, какое здание собирается строить.
Это меняет и разговор о цене вето. Сравнивать нужно не «стоимость простоя команды» со стоимостью заседания комитета, а временное ограничение части работ со стоимостью переделки, если один вариант уже фактически реализован, а компания потом выбрала другой.
Именно поэтому хорошее отлагательное вето должно сопровождаться не только условиями его снятия, но и понятной границей: что сейчас нельзя делать, а что проект продолжает делать без риска предрешить выбор.
В нашем кейсе именно поэтому вопрос отдельного контура НСИ оказался на управляющем комитете. Проектная команда могла подготовить варианты и рекомендации. Решение о новой организационной функции, её руководителе и дополнительном бюджете принадлежало уже не ей.
До этой границы можно обсуждать архитектуру. После неё — реализовывать выбранный вариант. Самое дорогое происходит посередине, когда решение ещё формально не принято, но команда уже «немного начала делать».
Решение принято. Что дальше?
После тяжёлого выбора хочется считать, что неопределённость закончилась. На самом деле закончилась только одна её часть.
Компания поняла, какие варианты допустимы, увидела их последствия и приняла компромисс. Но выбранный вариант ещё не создаёт ценность. Отдельный контур НСИ можно проектировать очень долго, ERP можно расширять до бесконечности, интеграционную схему — доводить до архитектурной красоты.
Следующий вопрос уже другой:
какую минимальную, но законченную бизнес‑ценность мы должны передать первой?
И здесь проект легко попадает в новую ловушку. После всех комитетов наконец хочется «перейти к реализации»: разбить решение на модули, подсистемы, интерфейсы, интеграции и миграции и начать закрывать технические куски.
Так появляется первая очередь, удобная для команды, но ещё ничего не меняющая для бизнеса. Есть справочник, но нет процесса его использования; есть интеграция, но нет сквозного сценария; есть новый интерфейс, но данные пока ведутся по‑старому. Проект движется, а законченной ценности всё ещё нет.
Поэтому выбор решения должен завершаться не только ответом «что строим?». Он должен подготовить следующий: какой законченный кусок нового способа работы можно передать первым?
Именно поэтому я не люблю трактовку MVP как «урезанной системы». Минимальность не должна означать недоделанность. Первая реализация может быть небольшой по объёму, но должна быть законченной по смыслу: пользователь проходит сценарий от начала до конца, процесс работает, данные проходят весь путь, а результат виден не только разработчику или архитектору.
Это уже тема следующей статьи.
А у выбора решения есть свой критерий завершённости. Не заполненная матрица и не победа варианта с лучшим баллом.
Мы понимаем, какие альтернативы были, почему выбрали эту, какую цену платим, какие проблемы всё равно останутся — и принимаем последствия выбора.
После этого можно строить.
До этого — рано.
Ранее в серии
Проект уже запущен, а проблему ещё не нашли — о диагностике инициативы до фиксации проектных обязательств.
Проект признали успешным. А бизнесу стало легче? — о проверке бизнес‑ценности и цепочке от возможности системы до эффекта.
Риск был у всех. Ответственность оказалась у одного — о владельце результата, полномочиях и Карте решений.
Мы производим гвозди по ГОСТу: как идеально выполнить неправильное ТЗ — о бизнес‑правилах и моменте, когда корректно реализованное требование всё равно ведёт к неправильному процессу.
У каждой системы своя правда. Кто решает, какая из них корпоративная? — об источниках данных, корпоративном правиле и ответственности за достоверность.
