А как вы подходите к методологии? Все проекты по одному, принятому в компании, стандарту или варируете в зависимости от проектов? К примеру, команда недоукомплектована, бэклог растёт, как и уровень стресса разработчиков - и тут они просят вас сократить количество митингов, ретро и вообще, давайте уйдём в канбан) но при этом все проекты в вашей компании ведутся по скраму и есть pmo
По порядку: Методология. Да, у нас есть своя методология проектного управления (МПУ), шаблоны документов и проектный офис. Уже на этапе пресейла понятно — сможем мы работать по МПУ, или нам придется адаптироваться под заказчика. У заказчика корпоративного сегмента зачастую имеется «своя» методология. Проекты с вендором выполняются по 1С:ТКВ. И тут рынок нам диктует правила.
Недоукомплектованная команда и растущий бэклог — это наши реалии. Методология и инструменты помогают жить в этой реальности. Например нашей методологией предусмотрен сбор и фиксация матрицы требований с участием функционального заказчика. Каждое требование расшивается с понятным критерием приемки. А все что выходит за рамки, а это неизбежно, уже задача РП превратить в заявки на изменения.
Как, например, перестройка управления проектом, когда вынужденно переходили на недельные спринты по подсистемам с ежедневными митингами каждого исполнителя. Ну не взлетел проект по каскадной модели — перестроились, приоритизировали требования, запустились в две очереди. Ситуации бывали разные.
А как вы подходите к методологии? Все проекты по одному, принятому в компании, стандарту или варируете в зависимости от проектов? К примеру, команда недоукомплектована, бэклог растёт, как и уровень стресса разработчиков - и тут они просят вас сократить количество митингов, ретро и вообще, давайте уйдём в канбан) но при этом все проекты в вашей компании ведутся по скраму и есть pmo
По порядку:
Методология. Да, у нас есть своя методология проектного управления (МПУ), шаблоны документов и проектный офис. Уже на этапе пресейла понятно — сможем мы работать по МПУ, или нам придется адаптироваться под заказчика. У заказчика корпоративного сегмента зачастую имеется «своя» методология. Проекты с вендором выполняются по 1С:ТКВ. И тут рынок нам диктует правила.
Недоукомплектованная команда и растущий бэклог — это наши реалии. Методология и инструменты помогают жить в этой реальности. Например нашей методологией предусмотрен сбор и фиксация матрицы требований с участием функционального заказчика. Каждое требование расшивается с понятным критерием приемки. А все что выходит за рамки, а это неизбежно, уже задача РП превратить в заявки на изменения.
Как, например, перестройка управления проектом, когда вынужденно переходили на недельные спринты по подсистемам с ежедневными митингами каждого исполнителя. Ну не взлетел проект по каскадной модели — перестроились, приоритизировали требования, запустились в две очереди. Ситуации бывали разные.