Size: a a a

Архитектура ИТ-решений

2021 January 08

YG

Yuri Geronimus in Архитектура ИТ-решений
pragus
А как быть с "бизнес не знает что хочет", "бизнес хочет, но не то", "бизнес хочет странного/неподходящего"?
Я бы начал разбираться.
Если вы начали что-то делать, скорее всего кто-то за это «виртуально платит».
Значит кому-то у кого есть ресурсы что-то надо.

——
Если кому что-то надо - это тот самый бизнес кто «не знает чего хочет» - обычно либо он 1️⃣ не хочет говорить (например конфликты), 2️⃣ либо мы не можем его понять / задать вопрос так чтобы он рассказал.

Например, в 1️⃣ первом случае вероятно попробовать разные фреймы взаимодействия - один на один, стратегическую сессию, провести семинар с прототипом документа с описанием процесса ... А было у меня 4 месяца делали прототипы до утра вместе с ним, и только когда втерлись в доверие, он очень четко и прямо расскзаал что надо. Просто без доверия как-то не говорил)

А ещё бизнес ну очень благодарен если мы ему расскажем то, что он может от себя понести своему начальнику, это вообще!

Ещё есть такой приём: вот начали вы внедрять «CRMERPITSM», идёте к бизнесу спрашиваете: «а что вообще вам надо», они говорят «XYZ». Вы говорите «О, а это как раз и есть CRMERPITSM», и таким образом у них сразу принятие, вы реализуете маленькую штуку которая им поможет и внедряете «правильный CRMERPITSM».

А если все не так, то лучше передать ответственность за ИТ-систему тому бизнесу, который понимает что хочет.

——
Если это не тот бизнес, который «платит»- нам главное чтобы не мешали, так что здесь классическое управление стейкхолдерами. Но есть нюанс если «бизнес1 решил создавать ИТ-решение для бизнеса2», то как минимум нужно ответственность передать в бизнес2 (минимум часть, например, назвав PO, или функциональным заказчиком и ответственность пописать) и в УК включить зампреда оттуда иначе точно провал по моему опыту. Лучше все-таки передать это другому бизнесу полност.

А, ещё в годовые КПЭ успешность системы можно добавить бизнесу, тогда сразу лучше становится.

Во 2️⃣ втором случае - вспоминается мне, когда меня позвал помочь в проекте один топ и 2 часа на меня же орал что я «тупой» (хотя сам и позвал (!) ), пока я не подобрал что говорить с ним надо во фрейме «концептуальной модели данных», тогда разговор пошёл, и потом он был ну очень благодарен, что помог, а другие не могли, но эти 2 часа надо было выдержать конечно🥲) обычно помогало прийти с прототипом, прийти с функциональной картой, провести семинар Direct Design
источник

VU

Vitaly U in Архитектура ИТ-решений
Sergey
слои любят на презентациях. Их можно нарисовать для презентаций. Для разработки слои с презентаций обычно не помогают никак
Где не помогают? Кто любит? Про что такая авторитетная речь?
источник

S

Sergey in Архитектура ИТ-решений
тут вроде все высказывают мнение из собственного опыта. Поэтому может кому-то помогало, другому нет.  Общего подхода не выработаем, да и невозможен он. Областей слишком много
источник

VU

Vitaly U in Архитектура ИТ-решений
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
А это откуда такая красивая картинка ?
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Я в смысле хоуч первоисточник вот той самой матрицы, которая внизу подложена посмотреть. Откуда понятия "контекстный", "концептуальный" и "детальный" появились. Кто автор и почему он думает именно так.
источник

p

pragus in Архитектура ИТ-решений
Sergey
слои любят на презентациях. Их можно нарисовать для презентаций. Для разработки слои с презентаций обычно не помогают никак
Software does not run on category theory, it runs on real hardware. (с)
источник

S

Sergey in Архитектура ИТ-решений
картинка очень странная и хороший пример как картинка никак не поможет в разработке :)
источник

A

Alex in Архитектура ИТ-решений
Если бизнесу нужно "объяснять необходимость", то может не так уж и нужен, этот ваш архитектор?
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
Alex
Если бизнесу нужно "объяснять необходимость", то может не так уж и нужен, этот ваш архитектор?
Ну тут слово "нужен" необходимо правильно интерпретировать. Если оно про то, что "владельцы бизнеса готовы заплатить денег за его работу" - то конечно не нужен. Если термин "нужен", про то, что "бизнес факапит управление рисками, так как контекст поменялся, и без специалиста гаплык" - то нужно доказывать.
источник

YG

Yuri Geronimus in Архитектура ИТ-решений
Gennadiy Kruglov
Основная вылезшая проблема - команды не тестируют стеки и не понимают границы их применимости, возможности и ограничения. Даже не так - не хотят понимать. Потому что хайп/резюме дривен девелопмент
«Резюме дривен девелопмент» - это прекрасно)
источник

VN

V N in Архитектура ИТ-решений
Alexander Luchkov
Ну тут слово "нужен" необходимо правильно интерпретировать. Если оно про то, что "владельцы бизнеса готовы заплатить денег за его работу" - то конечно не нужен. Если термин "нужен", про то, что "бизнес факапит управление рисками, так как контекст поменялся, и без специалиста гаплык" - то нужно доказывать.
Но ведь для контроля за рисками есть специально обученный CRO зачем ещё один дорогой спец? :)
источник

AL

Alexander Luchkov in Архитектура ИТ-решений
V N
Но ведь для контроля за рисками есть специально обученный CRO зачем ещё один дорогой спец? :)
Это где такое есть ? Я вот впервые слышу прям про CRO. RE - даже видел.
источник

VN

V N in Архитектура ИТ-решений
Alexander Luchkov
Это где такое есть ? Я вот впервые слышу прям про CRO. RE - даже видел.
Это с подачи ЦБ должен быть такой товарищ в компании
источник

VU

Vitaly U in Архитектура ИТ-решений
Alexander Luchkov
Я в смысле хоуч первоисточник вот той самой матрицы, которая внизу подложена посмотреть. Откуда понятия "контекстный", "концептуальный" и "детальный" появились. Кто автор и почему он думает именно так.
Тут в чате
источник

VU

Vitaly U in Архитектура ИТ-решений
Это перевод
источник

P

Petr in Архитектура ИТ-решений
Yuri Geronimus
Здесь считаю архитектурный вопрос как раз - топ-менеджер обычно отвечает за надсистему (то есть определяет основные требования к надсистеме), в которую входит наша целевая ИТ-система. Например, надсистеме «закупки» и целевая система «автоматизация организации закупок».

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

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

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

При этом понятно, что предпочтения топ-менеджеров могут быть «не про пользователя». Но про стейкхолдера «пользователь» мы вроде умеем, и методологии есть, и курсы, и куча источников...
А как работать со стейкхолдером «Директор по розничному бизнесу», «Финансовый директор» в должности «члена правления» информации значительно меньше, особенно на русском, поэтому я захотел про это рассказать)
Поддерживаю. С топами корпоративному архитектору и нужно взаимодействовать: обеспечивать принятие стратегически правильных решений людьми, принимающими решения.
Стейкхолдеры следующих уровней являются инициаторами или/и пользователями, от которых зависит приоритизация и выбор конкретных ИТ-решений.
источник

P

Pavel in Архитектура ИТ-решений
Кто это?
источник
2021 January 09

G

Grigory in Архитектура ИТ-решений
опаньки
источник

G

Grigory in Архитектура ИТ-решений
источник