Size: a a a

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

2019 November 14

ES

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

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Savin
чтобы не черствело - есть процесс: "цикл Демминга-Шухарта", например
Приведи последнее своё действие по PDCA, пожалуйста
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Это как с Фрейдом - оно настолько старое, что то, что прижилось, кажется очевидным, а что не прижилось - наивным наукообразием времён борождения просторов космоса
источник

ES

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

EI

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

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Savin
чтобы не черствело - есть процесс: "цикл Демминга-Шухарта", например
OODA цикл Бойда ближе к реальности, кстати
источник

Р

Руслан in Архитектура ИТ-решений
В ит имхо ресурс всегда ограничение, соответственно все планирование идет от ограничений, а не от продаж, для случая, когда ресурс легко изменяемая величина. На уровне команды продукта она создается с ресурсом достаточным для необходимой производительности/результата. И необходимо регулярно корректировать ресурс команды. Здесь регулярность заведомо N циклов производства. Те в схеме барабан буфер веревка, по каждой производственной операции разброд и шатание, но на длинные периоды, крупные релизы например, это работает.Отличие ит производства от обычного: разная трудоемкость единицы работы внутри цикла, высокая стоимость переключения.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Alexey Pryanishnikov
Да, можно частично согласиться. Но TOC шире чем ФТ и НФТ (анализ). ТОС больше про процесс и про принятие решений. Примеры из жизни: сокращается (увольняется) половина команды поддержки приложения. Нанять быстро не можем или нет бюджета. Это становится узким местом системы. Со стороны разработки концентрируем усилия на увеличение поддерживаемости (supportability) приложения, разгружаем поддержку от рутинной работы. Другой пример - разработка выдает продукт быстрее, чем QA могут протестировать. В этом случае QA - узкое место. Просим разработчиков помочь QA - организовываем автоматизированное тестирование, больше времени DEV команды тратим на реализацию качественного продукта (другие виды тестов - unit, integration и т.д). Третий пример - разработчик остался один в проекте - он узкое место. Меняем процесс таким образом, чтобы он не тратил время непродуктивно - освобождаем его от не очень важных активностей (к примеру оценка того, сколько займет разработка релиза - на данном этапе на это не надо тратить время), позволяем выдавать непротестированный продукт, который сразу же идет в QA команду и они ему показывают где ошибки,  подробно расписывают случаи когда они возникают, на что обратить внимание.
Например:

"Третий пример - разработчик остался один в проекте - он узкое место. Меняем процесс таким образом, чтобы он не тратил время непродуктивно - освобождаем его от не очень важных активностей"

меняем на

"Третий пример - разработчик остался один в проекте - он узкое место. Он меняет процесс таким образом, чтобы он не тратил время непродуктивно - освобождает себя от не очень важных активностей"
источник

ES

Eugene Savin in Архитектура ИТ-решений
Eugene Istomin
OODA цикл Бойда ближе к реальности, кстати
Так это о том же, вроде.
источник

EI

Eugene Istomin in Архитектура ИТ-решений
Eugene Savin
Так это о том же, вроде.
ммм .. как я вижу, нет. В чём видишь сходство?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Alexey Pryanishnikov
Кстати, имхо, лучшее управленческое решение во всех вышеперечисленных ситуациях - перестать уже влезать с прямым управлением )
В том смысле, что люди сами перераспределят ресурсы и приоритеты наилучшим образом (а дальше длинная тирада про "если, конечно, они хоть сколько-нибудь мотивированы, нацелены на результат и им не запрещают отклоняться от регламентов")
источник

EI

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

ES

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

EI

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

KG

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

Р

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

EI

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

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
5. Понимаем наконец, что управленец не нужен )
источник

Р

Руслан in Архитектура ИТ-решений
Alexey Pryanishnikov
5. Понимаем наконец, что управленец не нужен )
Правильный управленец поддержал все эти переходы ресурсами... До уровня который нужен, а не для красоты
источник

EN

Evgeniy Nikonorov in Архитектура ИТ-решений
6. Делаем большую красную кнопку
источник