Size: a a a

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

2020 June 17

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
В моём исходном сообщении вилка про стечение обстоятельств / сознательную организацию. Вы или что-то другое комментируете, или я вас неправильно понимаю.
У вас в сообщении указана последовательность - сначала набралось нужное кол-во людей, а потом уже произошли преобразования. Мне же хочется указать на то, что преобразования уже должны происходить, чтобы эти люди появились (новые с подходящими позициями или старые, изменившие позиции).
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
да, коррекция данных скриптами. вроде были еще какие-то "админские" операции через, собственно, админку, но этого я сама уже не видела.
Со своей колокольни - это по-моему не оч хорошо. Бизнес-данные должен править владелец через пользовательские интерфейсы. Если интерфейса нет, то лучше чтобы поучаствовал аналитик, который пропишет логику скрипта с учётом бизнес и тех-контекста.
Если править руками сопровождения, которое не понимает бизнес-логику, то разве что заранее написанными скриптами или дёргая конкретные api. Но лучше чтобы сопровождение в бизнес-данные вообще не лезло. Имхо.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
У вас в сообщении указана последовательность - сначала набралось нужное кол-во людей, а потом уже произошли преобразования. Мне же хочется указать на то, что преобразования уже должны происходить, чтобы эти люди появились (новые с подходящими позициями или старые, изменившие позиции).
Хз. Как я писал выше, мне неясно как развивать / реорганизовывать большие (100+) коллективы. Не знаю что тут первым должно быть курица или яйцо.
Маленькие (~10) понятно. Там можно закрыть инициативой снизу при минимальной поддержке руководства. А вот большие хз.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
Со своей колокольни - это по-моему не оч хорошо. Бизнес-данные должен править владелец через пользовательские интерфейсы. Если интерфейса нет, то лучше чтобы поучаствовал аналитик, который пропишет логику скрипта с учётом бизнес и тех-контекста.
Если править руками сопровождения, которое не понимает бизнес-логику, то разве что заранее написанными скриптами или дёргая конкретные api. Но лучше чтобы сопровождение в бизнес-данные вообще не лезло. Имхо.
Там как раз такие аналитики и были, бизнес-логику они понимали в определенной степени (насколько это может быть для системы, написанной другой компанией и со скудной документацией). Под владельцем вы кого понимаете? У нас это были операторы системы, сотрудники определенных ведомств. Бизнес-логика определяла процесс обработки данных, за который выйти было нельзя, и просто так заново начать нельзя. В итоге возникали ошибки, которые исправлять приходилось только в данных в базе, через интерфейс возможности не было.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Если аналогичных кейсов оказывалось много, то дальше в развитие могла пойти задача - мол, доработать это, чтобы легко исправлять вот это. Но пока ее включат в какой-то контракт, могут уйти годы)
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Roman Tsirulnikov
Вертикальная организация команд и микросервисы помогают:
1. развитие и поддержку можно сосредоточить в одном орг.юните. Если дальнейние изменения начинат тормозить, гораздо проще ткнуть пальцем в конкретный проект “потому что вот тут было насрато”.
2. “плохие” проекты можно огородить от остальной системы и дать им тихо сгореть в своем маленьком аду
К сожалению, есть проекты (ГИСы), которые не могут сгореть, их нужно как-то делать. Я про это в основном. В остальном конечно согласен.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
Хз. Как я писал выше, мне неясно как развивать / реорганизовывать большие (100+) коллективы. Не знаю что тут первым должно быть курица или яйцо.
Маленькие (~10) понятно. Там можно закрыть инициативой снизу при минимальной поддержке руководства. А вот большие хз.
Имхо, чем больше коллектив - тем выше должен быть тот, кто вносит изменения. По статусу или личному авторитету. Если команда большая, то личный авторитет человека, в одно лицо внедряющего такие изменения, и не обладающего полномочиями, должен быть сравнимым с руководством этого коллектива. А обычно такие люди в линейных специалистах не засиживаются.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
Там как раз такие аналитики и были, бизнес-логику они понимали в определенной степени (насколько это может быть для системы, написанной другой компанией и со скудной документацией). Под владельцем вы кого понимаете? У нас это были операторы системы, сотрудники определенных ведомств. Бизнес-логика определяла процесс обработки данных, за который выйти было нельзя, и просто так заново начать нельзя. В итоге возникали ошибки, которые исправлять приходилось только в данных в базе, через интерфейс возможности не было.
Под владельцем - сотрудники бизнес-подразделения генерирующего данные.
В автоматизации не было заглушек на тупиковые/неправильные данные потому что исторически так сложилось или это от специфики бизнес-процесса было нереализуемо?
источник

RT

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

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
Под владельцем - сотрудники бизнес-подразделения генерирующего данные.
В автоматизации не было заглушек на тупиковые/неправильные данные потому что исторически так сложилось или это от специфики бизнес-процесса было нереализуемо?
Предполагаю, что оба случая, но со вторым я сталкивалась чаще. Например, нельзя так просто взять и изменить какие-то личные сведения гражданина РФ. Очепятались при вводе. Иваноф Иван Иванович, например. Никто не запрещает такую фамилию, и системе совершенно все равно, как оно написано. Ошибка оператора.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
Имхо, чем больше коллектив - тем выше должен быть тот, кто вносит изменения. По статусу или личному авторитету. Если команда большая, то личный авторитет человека, в одно лицо внедряющего такие изменения, и не обладающего полномочиями, должен быть сравнимым с руководством этого коллектива. А обычно такие люди в линейных специалистах не засиживаются.
Угу. Только полномочия сами по себе не предоставляют возможности быстро набрать ии развить команду. Да даже не быстро, а хотя бы гарантированно. Это в таком случае нужно сделать самому. Каким-то образом, если коллектив велик и беспросветен то хз каким. :)
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
И хз зачем, вот ещё нюанс :)
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Ну просто потому, что если человек это может - то думаю и что-то поинтереснее авгиевых конюшень найдёт. Ну или мб пройти для личного достижения. Один раз :)
источник

DK

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

GK

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

DK

Daria Kaftan in Архитектура ИТ-решений
Если коллектив велик и беспросветен - то надо его просвечивать, увеличивать прозрачность. Любое "хз" можно прояснить. Если надо, конечно.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
А что может быть интереснее, чем повысить КПД команды? И научиться повышать КПД у команд? Снизить трудозатраты на внесение изменений. Превратить экспоненту в логарифм или даже прямую )
Много чего. Например работать с экспертной командой. И как рядовой участник, и как руковолитель. :D
Повышение КПД, если стартовать с низкой базы. Это история про поиск и обучение персонала. До тех пор пока количество удачных попыток (если каждая пятая будет удачна это хорошо) не приведёт к формированию сильного коллектива. На мой взгляд, это не самая комфортная занятость. И уж точно не быстрая, и не гарантированная с тз результата. Но на вкус и цвет все фломастеры разные. :)
В том что касается лично меня - это не мой фломастер. :)
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Ну и нюанс, безотносительно комфорта, ещё и в том. Что какая-никакая гарантия результата (хоть и без привязки ко времени достижения) тут только на малых объёмах. Подход не масштабируется.
источник

DK

Daria Kaftan in Архитектура ИТ-решений
Vsevolod Shulaev
Много чего. Например работать с экспертной командой. И как рядовой участник, и как руковолитель. :D
Повышение КПД, если стартовать с низкой базы. Это история про поиск и обучение персонала. До тех пор пока количество удачных попыток (если каждая пятая будет удачна это хорошо) не приведёт к формированию сильного коллектива. На мой взгляд, это не самая комфортная занятость. И уж точно не быстрая, и не гарантированная с тз результата. Но на вкус и цвет все фломастеры разные. :)
В том что касается лично меня - это не мой фломастер. :)
Экспертная команда - она же как раз для этого и нужна. Хотя... может быть закрытая экспертная команда, на которой завязаны все важные решения, и никому хода туда нет, да никому оно и не надо и оно так и работает годами.
источник

VS

Vsevolod Shulaev in Архитектура ИТ-решений
Daria Kaftan
Экспертная команда - она же как раз для этого и нужна. Хотя... может быть закрытая экспертная команда, на которой завязаны все важные решения, и никому хода туда нет, да никому оно и не надо и оно так и работает годами.
Мы об одном? Я говорю про развитие коллектива по экспертизе. А не про отладку работы уже сразу крутых ребят. :)
источник