3.1.1.Agile-методологии
Для начала нужно сказать, что даже PMI перестал считать гибкие методологии лженаукой и на сегодня в PMBOK входят описания гибких и гибридных проектных технологий.
В случае разработки софта в целом и определенной функциональности при развитии ERP-системы гибкие методологии хорошо помогают добиваться успеха быстро и качественно. Далеко не всегда можно полноценно заранее спланировать и зафиксировать в требованиях и дизайне подробный план работ. Иногда проще развивать готовый прототип или уже запущенную систему итерациями, небольшими модификациями, дающими сразу готовый результат для пользователей (и обратную связь от них) и сохраняющими работоспособную систему.
Для внедрения ERP-системы с нуля такой способ может не подойти, тут потребуется первично все спроектировать, спланировать и двигаться по этапам. Хотя на практике для ситуаций, когда система ERP ставится на новый бизнес (стартап) и компания готова подстраиваться под возможности системы «из коробки», гибкие методологии применимы и дают быстрый результат. Например, быстрое внедрение 1C:ERP за три месяца в объеме, достаточном для работы компании: производство, закупки, продажи, регламентированный учет. А уже следующими итерациями, в рамках проекта развития, довнедрение прочих подсистем: казначейство, бюджетирование.
Мнение практиков в поддержку гибких походов для ERP-проектов из круглого стола семинара по 1С:ERP в апреле 2019 г.: «ERP-система замечательно внедряется частями. Главное – грамотно спланировать этапы внедрения. А функционал системы настолько велик, что спроектировать все от и до качественно заранее очень сложно, поэтому можно использовать гибкие подходы с короткими итерациями выпуска рабочей версии».
Гибкие методологии хорошо подходят для частых выпусков работоспособных версий. И в связи с этим с успехом применяются при разработке и развитии некоторых программных продуктов с частой доставкой новой функциональности до конечного пользователя.
Обычная практика и мнение против гибких методик для ERP: «Внедрение ERP-системы часто проходит по классическим проектным методологиям в силу объемности и сложности внедряемой функциональности, когда нужно все четко спроектировать, спланировать и оценить».
На сегодняшний день грань между методологиями, в принципе, размывается и хорошо сочетаются гибкий подход с классическим – так называемые гибридные подходы, например: высокоуровневое планирование и этапность проекта, а внутри этапа разработки – гибкие итерации «разработка – тестирование» и частый выпуск релизов в эксплуатацию.
Рис. 3.1. Фото с примером доски задач по agile-методологии
Гибкие методологии возникли в ИТ-сфере в начале 2000-х годов, потом стали применяться в других сферах деятельности.
В гибких методологиях есть своя философия, и для того, чтобы привить полноценно методологию компании и сотрудникам, нужно приложить определенные усилия. На рынке присутствуют компании – тренеры agile, которые проводят обучение команд и помогают выстроить весь процесс с нуля.
Будет заблуждением считать, что «гибкость» – это «когда нет методологии». Нет! Во всех методиках есть свои правила, которые нужно соблюдать, какими бы странными они ни казались поначалу.
На практике в конкретной компании происходит трансформация гибких методологий из оригинальной системы в удобную для бизнес-процессов компании, так как начинаются отступления от оригинальной системы: «Мы только разик сделаем как обычно, а потом снова все как положено по методологии». В итоге получается адаптация и получение какой-то гибридной методологии. Это нормально, главное, чтобы методология вообще была и давала положительный результат.
В данной книге не будет подробного рассмотрения гибких методологий и отличий Scrum от Kanban или как организуется парное программирование в Extreme programming. Это все очень интересно и можно изучить самостоятельно.
Если есть желание применять гибкие методики, лучше опираться на более классические проектные технологии, чтобы было полное понимание, от чего отказываться в пользу «гибкости» и к чему это может привести. А не по принципу: «У нас все гибко, и всякие там непонятные вещи из управления проектами нам совсем не нужны».
При этом совместить гибкие методологии с классическим подходом именно в разработке (а не консалтинге, анализе бизнес-процессов и дизайне системы) вполне можно: после декомпозиции (пусть высокоуровневой) на задачи саму разработку можно гибко вести «спринтами» и итерациями на быстрый результат с вовлечением заказчика и минимумом проектной документации.
Из опыта практиков гибких методик для внедрения ERP: «Спринты и итеративность при моделировании тоже крайне эффективны, а не только на этапе разработки. Также сам этап запуска системы спринтами, разбитыми по разной функциональности и пользователям, позволяет сильно сократить градус экстрима на опытной эксплуатации».
Так что внедрение ERP по гибким методикам в ряде случаев вполне возможно – выбор тут за проектной командой.
