DK
Посыл такой - если ИТ тратит много денег, а бизнес не зарабатывает, бизнес придумает миллион причин, почему виновато ИТ.
а если оно реально виновато?))
Size: a a a
2020 June 16
GK
а если оно реально виновато?))
Мой мозг такой вариант отторгает))
AM
Скорее не так: в скраме загрузка специалистов неравномерна
Ну то есть кто-то перерабатывает, а кто-то простаивает?
DK
Мой мозг такой вариант отторгает))
У меня иногда создается впечатление, что ИТ - это такая бездонная бочка, которая слопает любой бюджет, если дать ей волю.
DK
Потому что совершенно непрозрачно же, за что бабки плотются.
GK
Есть компании, которые пытаются сделать ИТ прозрачным и отобразить расходы на бизнес линии.
DK
Ух ты. Это что-то из разряда прекрасного будущего, или все-таки из разряда клизмы по всему ит-организму?
RT
Ну то есть кто-то перерабатывает, а кто-то простаивает?
Как-то так, да.
В нормально организованной команде, условно “простаивающие” члены команды заняты задачами сопровождения, рефакторинга, обучения
В нормально организованной команде, условно “простаивающие” члены команды заняты задачами сопровождения, рефакторинга, обучения
GK
Ух ты. Это что-то из разряда прекрасного будущего, или все-таки из разряда клизмы по всему ит-организму?
Пока не понятно
I
А как вы делите, что вот это - инвестиция, а это - проект, который должен приносить прибыль? Тогда надо смотреть не прибыль по конкретному проекту, а прибыль по всей серии.
Для инвестиций обычно создается бизнес-план, где предусматривается в какие сроки проект должен выйти на самоокупаемость. Этому предшествует тонкая работа маркетологов. Но, как я уже говорил раньше, расходная часть (как и темпы разработки), при неправильной постановке вопроса могут выйти на экспоненциальный уровень роста. Так что про бездонную бочку Вы недалеко от истины.
I
У меня иногда создается впечатление, что ИТ - это такая бездонная бочка, которая слопает любой бюджет, если дать ей волю.
Очень напомнило Закон Паркинсона, что работа занимает все отведенное время.
RT
Час назад снова общался с топами. И снова вижу видение задачи исключительно как “сделать и запустить”. Как это поддерживать, обслуживать, вносить изменения - снова откровения, которые надо рассказывать снова и снова. Для крупной ИТ системы основные затраты лежат области внесения изменений в старое, а не в создании нового.
IG
Час назад снова общался с топами. И снова вижу видение задачи исключительно как “сделать и запустить”. Как это поддерживать, обслуживать, вносить изменения - снова откровения, которые надо рассказывать снова и снова. Для крупной ИТ системы основные затраты лежат области внесения изменений в старое, а не в создании нового.
Мягко сказано. Основные затраты -в исправление того, что должно быть продумано при проектировании, но не продумано.
AM
Вот кстати да: scrum vs утилизация.
Организация предприятия по scrum командам минимизирует задержки/простои задач, но неэффективно утилизирует ресурсы.
Организация предприятия по отделам эффективно утилизирует ресурсы, но дает слабо предсказуемые задержки/простои задач.
Менеджмент пытается поймать обоих зайцев сразу.
Организация предприятия по scrum командам минимизирует задержки/простои задач, но неэффективно утилизирует ресурсы.
Организация предприятия по отделам эффективно утилизирует ресурсы, но дает слабо предсказуемые задержки/простои задач.
Менеджмент пытается поймать обоих зайцев сразу.
Вот тут говорится, что по отделам тоже простои. Получается вся разница в предсказуемости?
RT
Вот тут говорится, что по отделам тоже простои. Получается вся разница в предсказуемости?
По отделам простаивают задачи. Люди в это время занимаются другими задачами. Получается как-бы эффективная утилизация времени людей, но задачи проходят по конвейеру долго, потому что должны пройти по всем отделам, а в каждом свои задачи и приоритеты, да и свалить проблему на смежников тоже классика.
RT
Выяснить “где застряло” бывает не всегда просто
AM
А, теперь мысль понял
AM
Но вроде как против этого вертикальные команды придумали
RT
Команда отвечает за задачу, минимизируются последовательные передачи задачи между разными орг.единицами. Задача проходит до релиза быстро и предсказуемо (один орг юнит отвечает за всю задачу), но заплатить за это придетя неравномерной утилизацией ресурсов. В задаче А нужно 10 юнитов ресурсов фронтенда, 5 юнитов бэкенда. В задаче Б нужно 5 юнитов фронтенда, 7 бэкенда.
F
Тут личный опыт авторов. Вы такое встречали. По сути все это никак не зависит от инструментов. Не инструмент, а люди, что в итерационном водопаде, что в аджайле могут создавать и то и другое.