Size: a a a

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

2019 November 29

DZ

Denis Zarin in Архитектура ИТ-решений
Глава 7. Очень рекомендую эту книгу.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Dmitriy Larionov
ROI разве не от EBITDA и CapEx считается?
Как угодно, это не часть стандарта. Вообще мимо учёта может, из других показателей -- через DCF, к примеру.
источник

DL

Dmitriy Larionov in Архитектура ИТ-решений
Ну я считаю, что это запутывание, считать так, что ROI с CapEx и EBITDA не билось. Этим все штуки для того и водились.
источник

DL

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

DZ

Denis Zarin in Архитектура ИТ-решений
Вы про разные перспективы сейчас. Анализ инвестиций -- это одно. Есть набор методов, практика. ROI -- очень общий подход, есть много вариаций по реализации.

А есть учет . Это другое, там стандарты. Потому что фин рынок и государство, надо уметь все сравнивать и считать одинаково.

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

DZ

Denis Zarin in Архитектура ИТ-решений
Дмитрий, выше очень интересная книжка. Посмотрите, должно понравиться! Там и про методы, и разбор реальных кейсов, и написано очень легко.
У автора вторая книга -- не менее интересная, кстати!
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Sergey Lukin
Посоветуйте фрейворк или тул для следующей задачи
1) Есть пачка микросервисов с неплохим REST API
2) Пока не хочется стоить свой DataPool/Lake/DWH со сбором и актуализацией данных.
3) Есть желание строить отчеты, которым нужны данные из нескольких MS
А у вас, вроде, уже и так есть ELK в ландшафте? Можно же logstash натравить на бд и/или api (если оно отдаёт нужные данные), не только на логи
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Vitaly Derbin
кмк, проблема тут не в legacy и compliance, а в головах и металитете: для кадров из СНГ, на мой взгляд, ваще свойственен высокий уровень фрустрации и скепсиса по отношению к галере, а для успешности аджайла очень важна чувство единства и ассоциации себя и компании(для достижения той самой Кокберновская "высокомотивированной команды"). В стартапе кадры подбираются часто не только на основании компетенций, но и по некоей эмоциональной близости, а в крупных компаниях такое получить очень сложно => agile из процесса направленного на получение общего value превращается в карго-культный набор митингов "потому что в календаре стоит".
Попалась под руку довольно эмоциональная статья, которая описывает симптомы.
Но самое интересное это комментарии к ней, они описывают причины:

Аджайл, как и другую методологию, нет смысла оценивать, если не принимаешь правила игры. Подобные инструменты — инструменты колониальной политики, причем, римской. Когда колонизатор не собирается делиться идеями и целями, а требует ресурсов и прибыли. Поэтому команде выдаются порции информации, чтоб она не могла увидеть картину-продукт целиком и можно было в любой момент его забрать с минимальным ущербом. Поэтому выгодно работать со студентами с горящими глазами без какого-либо опыта и претензий. Потому что опытный человек способен распознать картину по фрагментам и, например, развить идею в свою пользу.
Если команда объединена идеей, знает четко цели, задачи и методы решения проблем ей не нужны всякие прихлебатели-паразиты. Это опасный конкурент — субъект, а не объект политики. С ним нужно считаться, договариваться, либо уничтожить. Низводи лидеров, выращивай серость и посредственность. Работай на процесс, а не на результат. Разделяй и властвуй!
https://habr.com/ru/post/430890/#comment_19412148


В России самый распространенный вариант — организации-оборотни: красная культура, завернутая в желтую и оранжевую мантии. То есть самый худший вариант. Культура двойных стандартов. Когда вроде бы в конторе есть правила, стандарты, а в политиках прописано как люди и уважение к ним наша ценность, а на деле любые правила нарушаются руководством, из персонала, давят соки и главная парадигма "я начальник ты дурак"
https://habr.com/en/post/430890/#comment_19484264


В строчке, которую я процитировал выражена вся проблема — Agile в таком виде, какой есть в большинстве фирм сейчас, это не Agile. Это профанация. И если ваша Scrum-команда не может принять решение НЕ работать в open-space и если она не может получить обоюдную прозрачность и участвовать в принятии решений о продукте, то это не Agile. Это потогонка и микроменеджмент под нарядной драпировкой.

Ну а решение одно — внедрять ценности, а не фреймворки. А ценности — Самоорганизация и Самоуправление, Прозрачность, Психологическая безопасность и Непрерывное улучшение
https://habr.com/en/post/430890/#comment_20396051


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

DZ

Denis Zarin in Архитектура ИТ-решений
Roman Tsirulnikov
Попалась под руку довольно эмоциональная статья, которая описывает симптомы.
Но самое интересное это комментарии к ней, они описывают причины:

Аджайл, как и другую методологию, нет смысла оценивать, если не принимаешь правила игры. Подобные инструменты — инструменты колониальной политики, причем, римской. Когда колонизатор не собирается делиться идеями и целями, а требует ресурсов и прибыли. Поэтому команде выдаются порции информации, чтоб она не могла увидеть картину-продукт целиком и можно было в любой момент его забрать с минимальным ущербом. Поэтому выгодно работать со студентами с горящими глазами без какого-либо опыта и претензий. Потому что опытный человек способен распознать картину по фрагментам и, например, развить идею в свою пользу.
Если команда объединена идеей, знает четко цели, задачи и методы решения проблем ей не нужны всякие прихлебатели-паразиты. Это опасный конкурент — субъект, а не объект политики. С ним нужно считаться, договариваться, либо уничтожить. Низводи лидеров, выращивай серость и посредственность. Работай на процесс, а не на результат. Разделяй и властвуй!
https://habr.com/ru/post/430890/#comment_19412148


В России самый распространенный вариант — организации-оборотни: красная культура, завернутая в желтую и оранжевую мантии. То есть самый худший вариант. Культура двойных стандартов. Когда вроде бы в конторе есть правила, стандарты, а в политиках прописано как люди и уважение к ним наша ценность, а на деле любые правила нарушаются руководством, из персонала, давят соки и главная парадигма "я начальник ты дурак"
https://habr.com/en/post/430890/#comment_19484264


В строчке, которую я процитировал выражена вся проблема — Agile в таком виде, какой есть в большинстве фирм сейчас, это не Agile. Это профанация. И если ваша Scrum-команда не может принять решение НЕ работать в open-space и если она не может получить обоюдную прозрачность и участвовать в принятии решений о продукте, то это не Agile. Это потогонка и микроменеджмент под нарядной драпировкой.

Ну а решение одно — внедрять ценности, а не фреймворки. А ценности — Самоорганизация и Самоуправление, Прозрачность, Психологическая безопасность и Непрерывное улучшение
https://habr.com/en/post/430890/#comment_20396051


Вот похоже ключевое отличие условного старпапа и энтерпрайза. Одним из абсолютно необходимых условий реализации аджайла является возможность влияния команды на принятие решений, наличие обратных связей, обеспечивающих саморегуляцию системы.
Как это реализовать в рамках энтерпрайза задача весьма нетривиальная.
Роман, не ради холивара -- правда интересно:
А как самоорганизация и решения про open space попали в Agile?
В смысле, в манифесте вроде про это нет?
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Здесь я процитировал чужие комментарии, автор явно был недоволен openspace. Для меня этот аргумент неважен,
важен принцип участия в принятии решений.

“ Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The best architectures, requirements, and designs
emerge from self-organizing teams.


http://agilemanifesto.org/principles.html
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Проблема в том что “самоорганизовываться” способны высоко компетентные и самодисциплинированные люди, коих все-же не так много. То есть снова упираемся в подбор кадров.
источник

DZ

Denis Zarin in Архитектура ИТ-решений
Roman Tsirulnikov
Здесь я процитировал чужие комментарии, автор явно был недоволен openspace. Для меня этот аргумент неважен,
важен принцип участия в принятии решений.

“ Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The best architectures, requirements, and designs
emerge from self-organizing teams.


http://agilemanifesto.org/principles.html
Спасибо! У меня и не к вам претензии))

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

DZ

Denis Zarin in Архитектура ИТ-решений
Roman Tsirulnikov
Проблема в том что “самоорганизовываться” способны высоко компетентные и самодисциплинированные люди, коих все-же не так много. То есть снова упираемся в подбор кадров.
Я с другой стороны этого холивара, при всем уважении))
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Я тоже не ради холивара, я ищу решение задачи, поэтому за любые мнения буду благодарен)
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Кому нибудь про ROI через COSO второе разжевать надо?
источник

KG

Kirill Gorin in Архитектура ИТ-решений
и в рот положить
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Kirill Gorin
и в рот положить
тебе не буду
источник

KG

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

IN

Igor Nikolskiy in Архитектура ИТ-решений
Гугли
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Хугли
источник