Можно разбить понятие компетенции на - язык, знание инструментов, знание, как в целом система работает. Языку обучить не так сложно, но нужно его постоянно использовать, кроме того, он должен быть приземлен к терминологии компании, если она прижилась и работает. Инструментам тоже несложно обучить, если есть качественный онбординг, обучение и наставник, дающий обратную связь. Как все инструмены собрать в систему - тут нужна экспертиза методолога, у которого должен быть кругозор по разным фреймворкам, методам и их релевантности в конкретном контексте. Но большинству компетенции по системе не нужны. В итоге, если система грамотно собрана, то участникам достаточно общаться на одном языке и грамотно использовать инструменты. Это более чем реальная задача )
В моей практике это все же скорее исключение, нежели чем правило. Но если отдельная задача (доработка) начинает обрастать дополнительными требованиями, превращаясь в проект, то владелец процесса - ответственный за delivery или проектный офис должен поднять флаг и вынести ее повторно на рассмотрение на ЛПР или комитет, который присваивает категорию инициативам (проект, большая задача, задача).
Да, а главное объективно. За базар нужно так или иначе отвечать ) Хотя, конечно, итоговая точка это, когда конкретный элемент мигрируемой системы заработал в целевой системе и больше не используется в исходной.
Если же речь про то, в каком пространстве собираются необходимые практики, то мы много использовали виртуальную доску Miro, а сейчас периодически используем МТС Линк.
У меня есть 2 ответа на ваш вопрос в зависимости от его интерпретации.
Если вы имеете ввиду, что база знаний может являться артефактом - то, конечно, это хорошая практика, которая помогает избежать изобретения велосипеда на новых проектах.
Если же речь идет о том, можно ли использовать базы знаний с инструментами управления, то тоже да. Мы с профессором Сколково Павлом Алферовым создали такую базу, с которой можно ознакомиться по ссылке https://brizpm.ru/. Там под каждый аспект проекта можно подобрать необходимые инструменты.
Спасибо за комментарий. Действительно важно не только наличие правила или шаблона, а чтобы они органически выросли внутри компании, чтобы она до них дозрела. Лучше пусть "реестр рисков" и необходимые ритуалы называются "реестром проблем" и работают, чем формы, к которым все относятся как к бюрократии. Кстати часть правил отторгается потому что они не приземлены на реальные проекты, а как-будто повешены в воздухе - типа "делайте и все". А вот если что-то неполезно или не используется, хотя полезно, нужно выпиливать или допиливать, чтобы работало или выкидывать в корзинку. Нет ничего хуже, чем правило, которые не работает, и все знают об этом.
А были ли в вашей практике еще примеры правил, которые проросли снизу, из конректных проектов, а потом прижились во всей компании?
Масштабность тут в контексте использования Jira именно для управления проектами. Про управление продуктовой разработкой мы НЕ писали. Переводили = мигрировали?Делали то что? Кстати, с нетерпением вашего кейса на Хабре. Ознакомлюсь с большим интересом.
Кейс реализовали уже какое-то время назад. К сожалению, по разным причинам его согласование затянулось. Также не очень понимаю, что могу добавить еще по вашим вопросам, если вы задаете ровно те же вопросы, на которые мы отвечаем в статье.
Мы ничего не говорим про то, что подошло бы еще. У нас не было такой цели. Если есть классный кейс, как вы все то же сделали на Redmine, то с интересом ознакомлюсь с этим опытом, опубликованным на Хабре.
Экосистема Atlassian в разы, если не на порядок превосходит возможности яндекс.трекера, я не про "голую" Jira. Странно даже сравнивать.
Если есть более масштабный кейс не по количеству пользователей Jira (тут Сберу нет равных), а по использованию Jira как ИСУП, то ознакомлюсь с большим интересом, лучше конечно в виде подробной статьи на Хабре, а не мутных намеков.
Рад вашему успеху. Расскажите о своем кейсе на Хабре с деталями, дэшбордами, сроками реализации и восторженными отзывами пользователей. С интересом изучу. Особенно интересно, что вы сделали в Jira по управлению проектами. ИСУП - это всего лишь ПО, которое решает задачи по управлению проектами, большинство задач по управлению проектами можно решить в Jira или с помощью ее плагинов. Также поделитесь критериями по которым вы отделяете таск-трекер от ИСУП. Думаю, будет интересно не только мне. Ну и будет что обсудить.
Что такое Сбер я знаю прекрасно. Только не стоит путать Jira-проекты и управление кросс-функциональными проектами в Jira. Буду раз, если поделитесь тем, как реализовано управление проектами в Сбере со деталями, скриншотами и отзывами пользователей и заказчиков.
Спасибо за классное решение. Сотрудники бегают за решениями и советами, потому что так привыкли, удобнее, легче потом спихнуть ответственность, потому что ЧСВ босса помогает сохранять эту модель взаимодействия.
А какую конкретику вы бы хотели? В статья, правда, акцент был больше на проблематике, чем на инструментах. Мы пока пытаемся понять, что больше откликается аудитории Хабра. Далеко не все любят душные практические детали.
Надо разобраться, почему все время надо ждать Директора. Возможно не хватает полномочий для самостоятельного решения или может стоит пакетировать вопросы, чтобы каждый раз не висеть в очереди. Важно Директору показать последствия того, что его приходится ждать. Но пока выглядит как баг процесса, если вот по 2 недели надо было ждать. Во многих организациях ждут месяцами серьезных решений.
Можно разбить понятие компетенции на - язык, знание инструментов, знание, как в целом система работает. Языку обучить не так сложно, но нужно его постоянно использовать, кроме того, он должен быть приземлен к терминологии компании, если она прижилась и работает. Инструментам тоже несложно обучить, если есть качественный онбординг, обучение и наставник, дающий обратную связь. Как все инструмены собрать в систему - тут нужна экспертиза методолога, у которого должен быть кругозор по разным фреймворкам, методам и их релевантности в конкретном контексте. Но большинству компетенции по системе не нужны. В итоге, если система грамотно собрана, то участникам достаточно общаться на одном языке и грамотно использовать инструменты. Это более чем реальная задача )
В моей практике это все же скорее исключение, нежели чем правило. Но если отдельная задача (доработка) начинает обрастать дополнительными требованиями, превращаясь в проект, то владелец процесса - ответственный за delivery или проектный офис должен поднять флаг и вынести ее повторно на рассмотрение на ЛПР или комитет, который присваивает категорию инициативам (проект, большая задача, задача).
Да, а главное объективно. За базар нужно так или иначе отвечать ) Хотя, конечно, итоговая точка это, когда конкретный элемент мигрируемой системы заработал в целевой системе и больше не используется в исходной.
Если же речь про то, в каком пространстве собираются необходимые практики, то мы много использовали виртуальную доску Miro, а сейчас периодически используем МТС Линк.
У меня есть 2 ответа на ваш вопрос в зависимости от его интерпретации.
Если вы имеете ввиду, что база знаний может являться артефактом - то, конечно, это хорошая практика, которая помогает избежать изобретения велосипеда на новых проектах.
Если же речь идет о том, можно ли использовать базы знаний с инструментами управления, то тоже да. Мы с профессором Сколково Павлом Алферовым создали такую базу, с которой можно ознакомиться по ссылке https://brizpm.ru/. Там под каждый аспект проекта можно подобрать необходимые инструменты.
Спасибо за комментарий. Действительно важно не только наличие правила или шаблона, а чтобы они органически выросли внутри компании, чтобы она до них дозрела. Лучше пусть "реестр рисков" и необходимые ритуалы называются "реестром проблем" и работают, чем формы, к которым все относятся как к бюрократии. Кстати часть правил отторгается потому что они не приземлены на реальные проекты, а как-будто повешены в воздухе - типа "делайте и все". А вот если что-то неполезно или не используется, хотя полезно, нужно выпиливать или допиливать, чтобы работало или выкидывать в корзинку. Нет ничего хуже, чем правило, которые не работает, и все знают об этом.
А были ли в вашей практике еще примеры правил, которые проросли снизу, из конректных проектов, а потом прижились во всей компании?
Отличное предложение! Учтем ваши пожелания на будущее.
Если честно, то думаю, что нет. Но лучше смотреть конкретные требования. В Битрикс можно много чего сделать.
Масштабность тут в контексте использования Jira именно для управления проектами.
Про управление продуктовой разработкой мы НЕ писали. Переводили = мигрировали?Делали то что? Кстати, с нетерпением вашего кейса на Хабре. Ознакомлюсь с большим интересом.
Кейс реализовали уже какое-то время назад. К сожалению, по разным причинам его согласование затянулось. Также не очень понимаю, что могу добавить еще по вашим вопросам, если вы задаете ровно те же вопросы, на которые мы отвечаем в статье.
Мы ничего не говорим про то, что подошло бы еще. У нас не было такой цели. Если есть классный кейс, как вы все то же сделали на Redmine, то с интересом ознакомлюсь с этим опытом, опубликованным на Хабре.
Экосистема Atlassian в разы, если не на порядок превосходит возможности яндекс.трекера, я не про "голую" Jira. Странно даже сравнивать.
Если есть более масштабный кейс не по количеству пользователей Jira (тут Сберу нет равных), а по использованию Jira как ИСУП, то ознакомлюсь с большим интересом, лучше конечно в виде подробной статьи на Хабре, а не мутных намеков.
Рад вашему успеху. Расскажите о своем кейсе на Хабре с деталями, дэшбордами, сроками реализации и восторженными отзывами пользователей. С интересом изучу. Особенно интересно, что вы сделали в Jira по управлению проектами. ИСУП - это всего лишь ПО, которое решает задачи по управлению проектами, большинство задач по управлению проектами можно решить в Jira или с помощью ее плагинов. Также поделитесь критериями по которым вы отделяете таск-трекер от ИСУП. Думаю, будет интересно не только мне. Ну и будет что обсудить.
Что такое Сбер я знаю прекрасно. Только не стоит путать Jira-проекты и управление кросс-функциональными проектами в Jira. Буду раз, если поделитесь тем, как реализовано управление проектами в Сбере со деталями, скриншотами и отзывами пользователей и заказчиков.
Ну или тебе можно платить зарплату твоего подчиненного )
Спасибо за классное решение. Сотрудники бегают за решениями и советами, потому что так привыкли, удобнее, легче потом спихнуть ответственность, потому что ЧСВ босса помогает сохранять эту модель взаимодействия.
А какую конкретику вы бы хотели? В статья, правда, акцент был больше на проблематике, чем на инструментах. Мы пока пытаемся понять, что больше откликается аудитории Хабра. Далеко не все любят душные практические детали.
Надо разобраться, почему все время надо ждать Директора. Возможно не хватает полномочий для самостоятельного решения или может стоит пакетировать вопросы, чтобы каждый раз не висеть в очереди. Важно Директору показать последствия того, что его приходится ждать. Но пока выглядит как баг процесса, если вот по 2 недели надо было ждать. Во многих организациях ждут месяцами серьезных решений.