Во-первых, поднять требования к latency - не вариант. Как писал в статье, речь идет о данных партнеров со своей ИТ-инфраструктурой. В СберБанк Онлайн число одновременных пользователей - миллионы. А среди партнеров есть те, у кого всего клиентов - сотня или несколько сотен тысяч. Чтобы они могли поддержать запросы от такого количества пользователей - им всю инфраструктуру пришлось бы выкинуть и поставить новую примерно равную Сберовской. А такая инфраструктура для их бизнеса и их числа клиентов очень-очень сильно избыточна. Аллегория: вам домой установить сервера ГосУслуг :)
А во-вторых, помимо производительности есть еще и отказоустойчивость. СберБанк Онлайн работает 24/7 с непрерывностью. У ряда партнеров бывает downtime. Если раньше в этот период продукты клиенту СБОЛа не отображались вовсе, что приводило к обращениям, а иногда и к жалобам - то теперь из cache берется актуальное состояние, даже если ИТ-системы партнера ушли во временную тех. недоступность.
Это смотря что считать time-to-market, от какого момента и до какого :)
Если мы говорим только о задаче наполнения cache-системы продуктами компаний-партнеров и отображения этих продуктов в СберБанк Онлайн, то с момента первого аналитического кик-офф - до внедрения в проме на очень ограниченном числе лояльных клиентов - прошло в среднем 9 месяцев. Потом еще примерно квартал каждая секция раскатывалась на всех клиентов - за счет того, что были обнаружены уникальные особенности в данных некоторых клиентов и надо было систему "доточить".
Секция "Пенсии" открывалась первой, в ней были продукты только НПФ Сбербанка. Секция "Инвестиции" шла следом, с нахлестом (не end-to-start), в ней были продукты еще трех ЮЛ.
В целом здесь правильнее говорить о программе проектов, т.к. еще каждое из ЮЛ должно было у себя внедрить МДМ-систему для хранения золотой записи по клиенту, а потом надо было еще связать профиль клиента этого ЮЛ - с профилем клиента в Сбере, и все это - отдельные проекты.
Программа в целом шла около трех лет. Конечно, и промежуточные стадии давали бизнес-эффект, поэтому t2m не совсем правильно оценивать в три года. И был еще период до меня, когда пытались решить задачу без проектной организации, тут без комментариев :)
Итого, я бы оценил tm усредненно в 9 или 12 месяцев. Последующие интеграции по существующим рельсам внедрялись быстрее, конечно.
Вы меня спросили - "где я почерпнул идею". Я вам ответил, где. И не просто почерпнул, а испытал на себе.
Конечно, я продолжаю управлять проектами и программами, просто как минимум на текущий момент в явном виде это так не называется. Хотя заказчики на такую методику управления есть и со стороны бизнес-подразделений. К слову, описанный проект по факту был программой из 10+ проектов, но это бы сильно перегрузило статью, которая и так - лонгрид.
И хорошо, что вы понимаете плюсы руководителя проекта, относительно его отсутствия. Поверьте, для многих с кем я пересекаюсь на работе, написанное в статье будет или полезной шпаргалкой или даже откровением.
Если для вас ничего из написанного не стало новостью - это тоже позитивная новость! Надеюсь, я смог ответить на вопрос "где почерпнул", и, возможно, на не заданный, "для кого статья" :)
В практике. В одной крупной организации в какой-то момент при Agile-трансформации закрыли проекты списочно, а сотрудников с ролью "руководитель проектов" распределили по командам и кластерам, где и назначили другие роли. Насколько мне известно, так случилось не в одной крупной организации, но уверенно могу говорить про одну.
2. В теории. Вот методология SCRUM на оф. сайте Scrum Guide | Scrum Guides Слева перечислены три роли: владелец продукта, скрам-мастер, разработчик. Других нет. SAFe я тоже изучал, там тоже роли РП не было.
Теперь к вам встречный вопрос: можете ли вы привести какую-либо Agile-based методологию, где роль РП описана в явном виде?
Спасибо за комментарий и вопросы!
Во-первых, поднять требования к latency - не вариант.
Как писал в статье, речь идет о данных партнеров со своей ИТ-инфраструктурой.
В СберБанк Онлайн число одновременных пользователей - миллионы. А среди партнеров есть те, у кого всего клиентов - сотня или несколько сотен тысяч.
Чтобы они могли поддержать запросы от такого количества пользователей - им всю инфраструктуру пришлось бы выкинуть и поставить новую примерно равную Сберовской. А такая инфраструктура для их бизнеса и их числа клиентов очень-очень сильно избыточна.
Аллегория: вам домой установить сервера ГосУслуг :)
А во-вторых, помимо производительности есть еще и отказоустойчивость.
СберБанк Онлайн работает 24/7 с непрерывностью. У ряда партнеров бывает downtime.
Если раньше в этот период продукты клиенту СБОЛа не отображались вовсе, что приводило к обращениям, а иногда и к жалобам - то теперь из cache берется актуальное состояние, даже если ИТ-системы партнера ушли во временную тех. недоступность.
Это смотря что считать time-to-market, от какого момента и до какого :)
Если мы говорим только о задаче наполнения cache-системы продуктами компаний-партнеров и отображения этих продуктов в СберБанк Онлайн, то с момента первого аналитического кик-офф - до внедрения в проме на очень ограниченном числе лояльных клиентов - прошло в среднем 9 месяцев.
Потом еще примерно квартал каждая секция раскатывалась на всех клиентов - за счет того, что были обнаружены уникальные особенности в данных некоторых клиентов и надо было систему "доточить".
Секция "Пенсии" открывалась первой, в ней были продукты только НПФ Сбербанка.
Секция "Инвестиции" шла следом, с нахлестом (не end-to-start), в ней были продукты еще трех ЮЛ.
В целом здесь правильнее говорить о программе проектов, т.к. еще каждое из ЮЛ должно было у себя внедрить МДМ-систему для хранения золотой записи по клиенту, а потом надо было еще связать профиль клиента этого ЮЛ - с профилем клиента в Сбере, и все это - отдельные проекты.
Программа в целом шла около трех лет.
Конечно, и промежуточные стадии давали бизнес-эффект, поэтому t2m не совсем правильно оценивать в три года.
И был еще период до меня, когда пытались решить задачу без проектной организации, тут без комментариев :)
Итого,
я бы оценил tm усредненно в 9 или 12 месяцев.
Последующие интеграции по существующим рельсам внедрялись быстрее, конечно.
Добрый день!
По срокам реализации чего именно?
То, что в скриншотах, внедрено два года назад.
Это же прекрасно, что вы восстребованы! :)
Вы меня спросили - "где я почерпнул идею". Я вам ответил, где. И не просто почерпнул, а испытал на себе.
Конечно, я продолжаю управлять проектами и программами, просто как минимум на текущий момент в явном виде это так не называется. Хотя заказчики на такую методику управления есть и со стороны бизнес-подразделений.
К слову, описанный проект по факту был программой из 10+ проектов, но это бы сильно перегрузило статью, которая и так - лонгрид.
И хорошо, что вы понимаете плюсы руководителя проекта, относительно его отсутствия.
Поверьте, для многих с кем я пересекаюсь на работе, написанное в статье будет или полезной шпаргалкой или даже откровением.
Если для вас ничего из написанного не стало новостью - это тоже позитивная новость! Надеюсь, я смог ответить на вопрос "где почерпнул", и, возможно, на не заданный, "для кого статья" :)
В практике. В одной крупной организации в какой-то момент при Agile-трансформации закрыли проекты списочно, а сотрудников с ролью "руководитель проектов" распределили по командам и кластерам, где и назначили другие роли.
Насколько мне известно, так случилось не в одной крупной организации, но уверенно могу говорить про одну.
2. В теории. Вот методология SCRUM на оф. сайте
Scrum Guide | Scrum Guides
Слева перечислены три роли: владелец продукта, скрам-мастер, разработчик. Других нет.
SAFe я тоже изучал, там тоже роли РП не было.
Теперь к вам встречный вопрос: можете ли вы привести какую-либо Agile-based методологию, где роль РП описана в явном виде?
Арбитром выступает корпоративный архитектор, курирующий трайб.
Если развилка между трайбами, то архитекторы договариваются между собой.
Договоренность отражается в архитектуре, которая становится артефактом и пруфом - все уже потом на нее ссылаются.
Спасибо, что подсветили опечатку - исправил ;) Это - мой первый пост, я думал, что у меня будет еще время перечитать внимательно и зачистить
Про сомнения - ок, но рассказываю свой опыт и как было ;)