Size: a a a

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

2019 November 14

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Руслан
Правильный управленец поддержал все эти переходы ресурсами... До уровня который нужен, а не для красоты
Ну я упрощаю ради смеха. Правильно "такого количества управленцев не нужно".
Это ж основная причина, почему все крупные конторы обламываются с переходом на гибкие методологии - куче мидл-и-выше менеджмента нужно просто встать и выйти нафиг (или переквалифицироваться, утратив власть), причём собственноручно подготовив к этому почву, а они что-то не горят желанием пилить насиженный сук
источник

ES

Eugene Savin in Архитектура ИТ-решений
Eugene Istomin
"Это не работает потому что ..."
1) люди не рационализируемы до процесса
2) то, что можно рационализировать до процесса сразу же черствеет
3) чтобы не черствело, но был процесс - необходимы команды, понимающие Конвея, а не TOC
"... понимающие Конвея" Евгений, а что можете на эту тему посоветовать почитать? А то я не только не понимаю, но и не знаю о чем это. Беглый гуглинг не помог
источник

EI

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

Зачем?
«Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации»
Можно Мелвину Конвею верить, можно проверять на практике - но закон работает :)
Эмпирический закон Мелвина Конвея
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Eugene Savin
"... понимающие Конвея" Евгений, а что можете на эту тему посоветовать почитать? А то я не только не понимаю, но и не знаю о чем это. Беглый гуглинг не помог
"Любая организация порождает продукт, напоминающий её (орг)структуру". Это скорее принцип, типа законов Мерфи
источник

ES

Eugene Savin in Архитектура ИТ-решений
Спасибо
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Alexey Pryanishnikov
"Любая организация порождает продукт, напоминающий её (орг)структуру". Это скорее принцип, типа законов Мерфи
Не, не оргструктуру - именно "структуру коммуникации в рамках оргструктуры"
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Eugene Istomin
Не, не оргструктуру - именно "структуру коммуникации в рамках оргструктуры"
Ну на самом деле, обе их (и да, системная шизофрения тоже найдёт в продукте отражение)
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Alexey Pryanishnikov
Ну на самом деле, обе их (и да, системная шизофрения тоже найдёт в продукте отражение)
Языком оргдизайна тот или иной отдел отличается по структуре-фактуре-текстуре коммуникации. А документы или желания ЛПр - это форма, которая удерживает коммуникацию
источник

Р

Руслан in Архитектура ИТ-решений
Alexey Pryanishnikov
Ну я упрощаю ради смеха. Правильно "такого количества управленцев не нужно".
Это ж основная причина, почему все крупные конторы обламываются с переходом на гибкие методологии - куче мидл-и-выше менеджмента нужно просто встать и выйти нафиг (или переквалифицироваться, утратив власть), причём собственноручно подготовив к этому почву, а они что-то не горят желанием пилить насиженный сук
Согласен "прирожденных убивать" себе подобных менеджеров не много)
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Руслан
Уровни зрелости : 1 думаем о том, чтобы все были загружены работой - утилизация ресурса приоритет, 2 думаем о том что все по процессу - как следствие специализация ресурса приоритет, 3 думаем о результате - универсализация ресурса приоритет для увеличения утилизации)))
Похоже на правду
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Мне шаг 3 кажется и не очевидным и неверным.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Из мыслей о результате не следует универсализация.
источник

IN

Igor Nikolskiy in Архитектура ИТ-решений
Phil Delgyado
Мне шаг 3 кажется и не очевидным и неверным.
Не медитировал ещё над мыслей. Просто отметку поставил 'перечитать'
источник

Р

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

PD

Phil Delgyado in Архитектура ИТ-решений
Тут есть вполне понятное противоречие. Универсала легче планировать, но он менее эффективен чем специалист и решает более простые задачи. Если проекты простые, то универсализация полезна. Если сложные - то вредна
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И универсал всегда дороже.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Простой членов команды не является проблемой, если при этом продвижение по проекту идёт с нужной скоростью.
источник

VA

Viktor Alexandrov in Архитектура ИТ-решений
Phil Delgyado
Простой членов команды не является проблемой, если при этом продвижение по проекту идёт с нужной скоростью.
Спорно. Упущенная выгода же
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Откуда там упущенная выгода?
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Руслан
Уровни зрелости : 1 думаем о том, чтобы все были загружены работой - утилизация ресурса приоритет, 2 думаем о том что все по процессу - как следствие специализация ресурса приоритет, 3 думаем о результате - универсализация ресурса приоритет для увеличения утилизации)))
4. Перестаем воспринимать людей, как станки.
источник