Size: a a a

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

2020 March 05

YB

Yury Batsyuro in Архитектура ИТ-решений
Roman Tsirulnikov
Наблюдаю этот эффект в реальности. ТЗ ставится как эскиз пользовательского интерфейса, а что там внутри бизнес-процесса как раз теряется.
Продакт это про картинки и эскизы, как там оно будет выглядеть для пользователя.
Но, например вопрос о финансовой схеме сервиса вызывает зависание мозга и искреннее непонимание чего тут хотят.
Это очень печально: команды с успехом делают красивые интерфейсы, но вообще не понимают как работает базовый сервис
Для этого есть бизнес-аналитики
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Yury Batsyuro
Для этого есть бизнес-аналитики
Спасает отчасти: инженер скатывается в кодера, пишет код который не понимает. Механически переводит ТЗ в код. Не может очобъясчнить почему так сделано, начинаются ситуативные заплатки
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Yury Batsyuro
Сколько раз делал ремонт: обязательно расштрабили — позвали. Пересчитал розетки, обратил внимание, что две забыли. Доштробили — позвали, получили добро на штукатурку. Доштукатурили — позвали, получили добро на обои. Поклеили — позвали...
так мы о разработке или ремонте уже? Я заказчик, я в душе не чаю, хорошо оно или плохо ВНУТРИ.Что снаружи ровно - ну ок, и то плохо понимать могу
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Phil Delgyado
А все равно качество звукоизоляции выясняются после окончания работ (
Решением проблем звукоизоляция занимаются не на этапе реализации, а на этапе проектирования. Как ни странно, в ПО такими вещами, как производительность, также занимаются на уровне проектирования. Иначе вообще не понятно, за что платят архитектору.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Воот, а проверить это как?)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Roman Tsirulnikov
Я не зря тут ною про некомптетентность “команд” в прикладном домене, сейчас это прямо проблема. Учить команды понимать бизнес-прцоессы системы.
Складывается ощущение, что мы (рынок) слишком быстро растём (разбухаем). Решаем задачи числом, а не умением.
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Gennadiy Kruglov
Именно. Иногда случаются парадоксальные вещи. Команда/группа людей работающая над проектом, забывает даже цель решения. На встречах львиная доля времени уделяется обсуждению "кнопочек", а в центре этой истории - UI дизайнер, герой нашего времени.
Может это потому, что из десятков и сотен технически грамотных решений популярным и успешным станут только 1-2, те где интерфейс получш?
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Или хороший UX-ер как-то мешает архитектору выполнять его работу?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Oleg Soroka
Или хороший UX-ер как-то мешает архитектору выполнять его работу?
Можно не буду отвечать) не хочется троллить) сорри
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Gennadiy Kruglov
Складывается ощущение, что мы (рынок) слишком быстро растём (разбухаем). Решаем задачи числом, а не умением.
В соседнем чатике про управление знаниями публиковали ссылку на материалы Росатома,  про их систему управления знаниями,
то есть про обучение сотрудников прикладному домену.
Видимо и мы подходим к такому же.
Принять что команды неспособны разобраться в своем домене самостоятельно, формировать группы внешних экспертов (аналитики, архитекторы), фиксировать знания, заниматься обучением
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Roman Tsirulnikov
В соседнем чатике про управление знаниями публиковали ссылку на материалы Росатома,  про их систему управления знаниями,
то есть про обучение сотрудников прикладному домену.
Видимо и мы подходим к такому же.
Принять что команды неспособны разобраться в своем домене самостоятельно, формировать группы внешних экспертов (аналитики, архитекторы), фиксировать знания, заниматься обучением
👍
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Roman Tsirulnikov
В соседнем чатике про управление знаниями публиковали ссылку на материалы Росатома,  про их систему управления знаниями,
то есть про обучение сотрудников прикладному домену.
Видимо и мы подходим к такому же.
Принять что команды неспособны разобраться в своем домене самостоятельно, формировать группы внешних экспертов (аналитики, архитекторы), фиксировать знания, заниматься обучением
Для больших компаний это нормально. Там и архитектор не архитектор всего, а архитектор какого-то кусочка.
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Gennadiy Kruglov
Можно не буду отвечать) не хочется троллить) сорри
Не, я не отрицаю - "случаи они всякие бывают". Просто случаи - это ещё не закономерности.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Daria Kaftan
Воот, а проверить это как?)
Проверить качество внутренней реализации может только архитектор. В водопаде он, делая проект и формирует этапы реализации так, чтобы он мог контролировать. В аджайле он выделяет то, что можно юниттестить, и следит за покрытием и за самим процессом разработки так, чтобы покрытие было реальными кейсами, а не просто 80%.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
В соседнем чатике про управление знаниями публиковали ссылку на материалы Росатома,  про их систему управления знаниями,
то есть про обучение сотрудников прикладному домену.
Видимо и мы подходим к такому же.
Принять что команды неспособны разобраться в своем домене самостоятельно, формировать группы внешних экспертов (аналитики, архитекторы), фиксировать знания, заниматься обучением
а можно ссылочку
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Daria Kaftan
а можно ссылочку
источник

DK

Daria Kaftan in Архитектура ИТ-решений
И на чатик можно
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Роман, про опыт Росатома по управлению знаниями много сказано. Вот один из моих докладов (аж 14 года), но за эти 30 минут детально разобраны все элементы СУЗ Росатома https://www.youtube.com/watch?v=EOec4Zvg_So
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Yury Batsyuro
Решением проблем звукоизоляция занимаются не на этапе реализации, а на этапе проектирования. Как ни странно, в ПО такими вещами, как производительность, также занимаются на уровне проектирования. Иначе вообще не понятно, за что платят архитектору.
Не, там и при ремонте дофига что можно испортить. Архитектор обеспечивает возможность звукоизоляции, а не гарантии таковой
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Roman Tsirulnikov
Роман, про опыт Росатома по управлению знаниями много сказано. Вот один из моих докладов (аж 14 года), но за эти 30 минут детально разобраны все элементы СУЗ Росатома https://www.youtube.com/watch?v=EOec4Zvg_So
на исходный чат так перейти не получается, или я где-то туплю
источник