В прошлый раз мы рассказали о том, зачем «Северстали» понадобилась информационная система управления проектами и из чего она состоит. Сегодня продолжим и расскажем о том, как мы управляли проектом внедрения ИСУП и какие уроки для себя вынесли в процессе. На связи снова Павел Архиереев, старший менеджер нашего 1С-центра.

В целом о проекте внедрения

Говоря об управлении проектом внедрения ИСУП, вначале есть смысл описать методику реализации проекта, которую мы применяли, с её управленческими и технологическими аспектами.

Раз мы реализуем готовое 1С-решение (хоть и с кастомизацией), то было бы логично использовать и готовые методики его внедрения от фирмы «1С». Но когда мы почитали их описание, то увидели, что они носят настолько общий и поверхностный характер, что их реальное применение показалось затруднительным. Поэтому мы использовали отдельные элементы таких широко известных и ставших классическими методик, как AIM (Application Implementation Method) от Oracle или очень похожей на неё методики ASAP (Accelerated SAP) от SAP.

Мы не стали применять эти методики в полном объёме и чистом виде, поскольку в силу своего исторического консерватизма и бескомпромиссности они требуют от проектной команды определенной организационной и технологической культуры, развитие которой в рамках отдельно взятого проекта мы не планировали. Кроме того, они базируются на предиктивном жизненном цикле, хотя и с элементами итеративности, и больше подходят для стабильных организационных сред с высоким уровнем определённости, то есть со стационарной, детерминированной моделью бизнес-процессов.

В нашем случае все было иначе: внутренние факторы предприятия постоянно менялись, бизнес-процессы перманентно эволюционировали, реестр пользовательских требований утратил свою актуальность ещё до старта проекта, а новые требования можно было выявить уже только по ходу пьесы. Такой проект можно было смело отнести к категории проектов с высоким уровнем неопределённости. А где неопределённость, там и Agile, который, конечно, в первую очередь ориентирован на разработку ПО, но который не без успеха можно использовать и для внедрения готовых бизнес-приложений с кастомизацией.

Внедрять 1С «из коробки» решили с Agile

Опыт применения Agile при внедрении готовых 1С-решений с глубокой кастомизацией у нас на тот момент уже был. В 2020 году мы успешно внедрили «1С: Транспортная логистика, экспедирование и управление автомобильным транспортом» в автотранспортном цехе (АТЦ) Управления транспорта ПАО «Северсталь». Это был первый и весьма удачный опыт применения Agile в области корпоративных 1С-систем «Северстали» — в том проекте практически все было сделано правильно. И у него было интересное техзадание: «Внедрить новую 1С-систему и перенести в неё из старой 1С-системы все лучшее и уникальное, что было разработано в течение последних 10 лет. Что именно является лучшим, Заказчик определит по ходу проекта». Ну чем не кандидат на Agile-внедрение?

В то время в группе компаний активно пропагандировалась Agile-философия, и Дирекция по развитию бизнес-системы «Северсталь» (БСС) успешно «продавала» её руководителям производственных подразделений и направляла квалифицированных Agile-тренеров в формирующиеся Agile-команды. Помимо Agile-коуча Дирекция по развитию БСС выделила в проект специально обученного SCRUM-мастера, а заказчик со своей стороны выделил «владельца продукта (product owner)», который также прошел специальное обучение на корпоративных курсах. Команда разработчиков насчитывала 5 универсальных высококвалифицированных специалистов, которые обладали широким спектром компетенций от бизнес-анализа, до технического проектирования и программирования, и которые на 100% были выделены именно в этот проект.

Все SCRUM-ритуалы мы выполняли неукоснительно. При живом SCRUM-мастере из БСС по-другому и быть не могло: комиссар в пыльном шлеме и кожаной куртке с маузером в руках настойчиво и мягко прививал команде Agile-культуру. Правда, не удалось разместить всю проектную команду в одном помещении с пробковой доской для бумажных карточек, но это на удивление оказалось не столь серьёзной помехой — Skype и JIRA вполне компенсировали распределённый характер команды. А последующие годы ковидной удалёнки только подтвердили жизнеспособность такой формы работы.

И пусть будет гибридный жизненный цикл

С учётом вышесказанного, в проекте внедрения ИСУП было решено использовать гибридный жизненный цикл: смесь предиктивного и адаптивного подходов. А в качестве базового организационного фреймворка использовать SCRUM. Проект был разбит на фазы, каждая из которых условно считалась либо предиктивной, либо адаптивной. Детерминированные фазы выполнялись по предиктивному Каскаду, а фазы адаптации (разработки) — по гибкому Аджайлу.

Такой гибридный жизненный цикл потребовал нескольких видов планирования. Для проекта в целом применялось классическое сетевое планирование с:

• диаграммой Ганта,

• структурной декомпозицией работ,

• критическим путём,

• контрольными точками.

Первый стартовый релиз системы планировали как последовательность нескольких спринтов, в ходе которых предстояло подготовить функциональность MVP.

Последующие инкременты системы мы видели уже как отдельные спринты с набегающей волной — когда в предыдущем спринте выявляются требования и проектируется концептуальный дизайн отдельных функций, а в последующем спринте осуществляется их разработка и поставка.

Но… SCRUM пришлось адаптировать под реалии проекта

Роль SCRUM-мастера с переменным успехом выполняли руководитель проекта со стороны заказчика и соруководитель проекта со стороны корпоративной ИТ-функции. Владельцами продукта выступали ключевые пользователи из разных функциональных направлений.

Команда разработчиков состояла из двух внешних (ООО «АйТиЛенд-Софт», ООО «Эрикос-Проект») и одной внутренней (АО «Северсталь-Инфоком») команд, каждая из которых размещалась в разных городах, имела свою организационную культуру и сложившиеся производственные стереотипы. Выровнять их под один знаменатель оказалось непросто. Кроме того, каждая команда была связана с заказчиком коммерческим контрактом. Интересно, что имели в виду праотцы Agile, когда декларировали, что «сотрудничество с заказчиком важнее контрактных ограничений»? Может быть, безразмерный сферический бюджет проекта в вакууме? Общая численность проектной команды насчитывала отнюдь не 6±3 человека, как предписывала методика Agile, а 60+ на пике. Самое время было задуматься о «SCRUM of SCRUMs», но времени на такие эксперименты у нас не было.

Зато удалось поэкспериментировать с длительностью спринтов

Фактическую скорость разработки (velocity) мы не измеряли, ограничиваясь оценкой фактического освоенного объема. Для разработки первого релиза у нас были двухнедельные спринты. Для интеграционного пользовательского приёмочного тестирования релиза применяли уже четырехнедельный спринт. После запуска первого релиза в эксплуатацию длину спринтов менять не стали. Четырехнедельные спринты позволяли оптимизировать административные издержки на их организацию и были удобны для ежемесячных взаиморасчётов с командами разработчиков.

Основные SCRUM-ритуалы были зафиксированы в форме контрактных обязательств и включали:

• планирование спринтов,

• демонстрацию результатов,

• пользовательскую приёмку (тестирование) компонент,

• пользовательскую приёмку (тестирование) релизов,

• поставку в продуктив и

• последующую стабилизацию эксплуатации.

10 измерений управления проектом внедрения ИСУП

Какие бы методики и жизненные циклы мы не применяли в проекте по внедрению ИСУП, в любом случае мы говорим об управлении несколькими измерениями (читай, ограничениями) управления проекта: содержанием, стоимостью, сроками, ресурсами, качеством и рисками. О них-то дальше и пойдёт речь.

1. Управление содержанием

Под «содержанием» в этом проекте мы понимаем пользовательские истории, например, «Как сметчик, я хочу формировать сметы, используя базисно-индексный метод». А также технические задачи, например: «Построить индекс полнотекстового поиска», «Настроить профиль APDEX», «Оптимизировать режим работы RLS». Эти истории и задачи составляют реестр требований, а если говорить на языке Agile — backlog продукта.

Бэклог проекта в *.XLSX

70% требований, существовавших на начало проекта по внедрению, были неактуальны. Как и положено проекту с высоким уровнем неопределённости, требования выявлялись по ходу дела на фоне культурной и организационной трансформации корпоративной сферы капитального строительства.

Вначале мы вели backlog в *.XLSX-файле, который размещали в сетевой папке с FTPs-доступом из интернета. Такой доступ было проще всего организовать для внешних разработчиков, но он исключал возможность многопользовательского редактирования файла. Поэтому приходилось выстраиваться в очередь и делить машинное время. Порой файл портился, и его восстанавливали из резервной копии с потерей части информации.

Файл *.XLSX содержал большое количество аналитик (столбцов). Там были:

• всевозможные идентификаторы (функциональной области, бизнес-процесса, требований);

• описание пользовательской истории; 

• техническая постановка;

• описание принципов реализации; 

• критерии приёмки; 

• оценка размера; 

• приоритет; 

• номер предполагаемого спринта и релиза; 

• ФИО заказчика, приёмщика;

• многочисленные статусы.

Позже, когда стали понятны другие способы подключения внешних разработчиков к различным корпоративным сервисам, файл *.XLSX переехал в хранилище на платформе Microsoft SharePoint, обеспечив режим многопользовательского редактирования, версионирования и резервирования.

Переход в JIRA

Он стал настоящей «манной небесной». Использованию JIRA долгое время противились многие участники проекта — и со стороны заказчика, и внешние разработчики. Но дозрели таки, вдоволь вкусив все прелести использования *.XLSX-файла. На момент миграции в JIRA, в *.XLSX-файле насчитывалось ≈700 реализованных требований, в то время, как в JIRA на момент написания статьи содержится ≈1034 требований.

2. Планирование спринтов

При планировании спринтов для оценки размеров (объёмов) требований (features) не удалось применить покер-планирование с использованием рядов Фибоначчи, тем не менее оценки объёмов команды разработчиков дифференцировались по технологическим этапам: проектирование, разработка, контроль качества, демонстрация, резерв на риски.

 Размер требований оценивался в классических человеко-часах. На применение «story points» мы не решились. Как сказал Вольтер, «лучшее — враг хорошего»: если работают простые человеко-часы, зачем применять инновации в виде «story points» с неочевидной выгодой?

3. Управление расписанием

Наш проект внедрения с гибридным жизненный циклом разбивался на предиктивные и адаптивные фазы. Количество и состав предиктивных фаз был понятен, поскольку определялся методикой внедрения «готовых» бизнес-приложений, а вот количество и состав адаптивных фаз было заранее неизвестно, поскольку количество и размеры пользовательских требований менялись.

Длительность работ предиктивных фаз мы оценивали экспертно или статистически. Например, сроки развёртывания серверной инфраструктуры оценивались на основе заключения системных администраторов, а сроки подключения пользователей — на основе статистики выполнения операций соответствующего регламента по управлению доступом пользователей.

Длительность адаптивных фаз была фиксированной и определялась длинной спринта. Количество адаптивных фаз прогнозировалось на основе оценки размера пользовательских требований и среднестатистической мощности команд разработки. Исходя из этих знаний, мы делали индикативное предположение о темпах «сгорания» требований к продукту и прогнозировали количество адаптивных фаз проекта.

4. Управление стоимостью

При управлении стоимостью объектом управления является бюджет проекта, а точнее разница между плановыми показателями бюджета и фактическими затратами с учётом их прогноза на конец проекта. Если разница положительная, то имеем профицит, то есть экономию, а если отрицательная, то имеем дефицит, то есть перерасход. Эта разница — и есть основание для принятия или непринятия соответствующего управленческого решения.

В этом проекте стоимость оборудования и лицензий на ПО была детерминирована, и управление затратами на приобретение таких активов сложностей не вызвало, хотя и здесь не обошлось без сюрпризов.

Управление затратами на консалтинг (на услуги внешних разработчиков) на коротком промежутке времени тоже было относительно простым. Собираем требования заказчика, оцениваем размер каждого требования, сумму размеров всех требований умножаем на тариф разработчиков и получаем плановую стоимость консалтинга в спринте. Далее контролируем отклонение фактической выработки разработчиков в спринте от плановой стоимости спринта. Если допустимое отклонение (tolerance) превышает пороговое значение, определенное контрактом, то договариваемся о способе урегулирования расхождения.

Все осложняется лишь тем, что реестр требований продукта постоянно эволюционирует, и, как правило, в сторону устойчивого роста его содержания. Это и вызывает трудности при расчёте прогноза затрат на конец проекта (ПЗГ) на длинном промежутке времени.

Единственным «предохранительным клапаном» здесь выступает конечность бюджета, ведь «выше головы не прыгнешь», а «из камня воды не выжмешь». Таким образом, управление стоимостью консалтинга происходит через управление содержанием, ибо они в данном проекте имеют линейную зависимость.

5. Управление качеством

Мы использовали два самых очевидных метода управления качеством:

1. «Контроль качества». Здесь мы применяем несколько способов функционального тестирования, которые являются частью законтрактованного регламента взаимодействия участников проекта — демонстрация компонент, пользовательское тестирование компонент, пользовательское тестирование релиза. Дефекты, выявленные в ходе тестирования, в зависимости от их критичности и трудоёмкости либо устраняли в процессе тестирования, либо выносили в следующий спринт.

2. «Гарантия качества». Это устранение дефектов, выявленных в процессе опытно-промышленной эксплуатации системы в течение гарантийного периода. Длительность и границы применения этого метода также были прописаны в контракте с внешними разработчиками.

6. Управление ресурсами

В реализации проекта принимала участие проектная команда, сформированная из сотрудников разных аффилированных и не аффилированных организаций.

Команда заказчика состояла из сотрудников Дирекции по инвестициям и производственных подразделений «Северстали», а также из сотрудников корпоративных проектных институтов. Приказ о формировании проектной группы со стороны заказчика порой включал до 40+ фамилий с разной степенью участия, правами и мерой ответственности. Кроме того, на стороне заказчика «играли» сотрудники корпоративной финансовой функции в лице ООО «Северсталь Центр Единого Сервиса».

Команда разработчиков состояла из представителей трёх организаций:  

• ООО «АйТиЛенд-Софт» — адаптация и внедрение «1C:PM» ≈ 13 человек;

• ООО «Эрикос-Проект» — адаптация и внедрение «1С:СМЕТА» и «СНБ» ≈ 9 человек;

• АО «Северсталь-инфоком» — адаптация и внедрение «1C:ERP» ≈ 15 человек, сопровождение «1C:PM» и «1С:СМЕТА» ≈ 5 человек.

7. Управление коммуникациями

Содержание коммуникаций в проекте в большей мере определялось ритуалами SCRUM:

• планированием спринтов,

• актуализацией статуса реализации,

• демонстрацией результатов,

• тестированием компонент или релизов.

 Эти основные ритуалы дополнялись разнообразными тематическими мероприятиями:

• совещанием по формализации или проектированию очередного, не вполне очевидного требования;

• совещанием по подключению к системе пользователей очередного строительного подрядчика;

• демонстрационным днём для будущих конечных пользователей;

• управляющим комитетом для заказчика и так далее и тому подобное.

8. Управление рисками

Систематическое управление рисками в форме специального процесса в проекте внедрения ИСУП не осуществлялось. Хотя спонтанно мы выявляли риски и даже прогнозировали, оценивали и купировали их. Как правило, это происходило во время мозговых штурмов или на статусных встречах.

Матрица рисков как таковая отсутствовала. Выявленные риски, имеющие высокую вероятность наступления и высокую степень влияния на результаты проекта, мы сразу же трансформировали в проектные задачи, фиксировали в бэклоге и ставили в план реализации в рамках очередного, а иногда и текущего спринта.

9. Управление закупками

Основную часть сырья и материалов, то есть серверного оборудования и лицензий на ПО, мы закупили еще в начале проекта. После ввода первого релиза в пром мы перманентно закупаем строительно-нормативные сборники (СНБ) в рамках специально заключенного договора поставки.

Закупка консалтинговых услуг по адаптации и внедрению ПО выполняется вендорами в рамках заключённых контрактов. По результатам планирования очередного спринта заказчик формирует заявки на выполнение работ, а затем передает их исполнителям. С точки зрения контрактов эти заявки представляют собой производственные заказы.

После того, как весь комплекс работ выполнен, поставка результата (продукта) завершается развертыванием программных компонентов в продуктивные экземпляры системы ИСУП (базы данных). Затем в процессе эксплуатации происходит их стабилизация, после чего выполненные работы актируются и оплачиваются.

10. Управление изменениями

Весь проект внедрения ИСУП — это чреда перманентных изменений и улучшений. Поэтому отдельного процесса управления «запросами на изменение» (ЗнИ) в проекте нет. Хотя в законтрактованном регламенте взаимодействия участников проекта есть раздел, описывающий порядок реализации «дополнительных» требований заказчика, который по сути описывает правила управления реестром требований к продукту.

11. Управление знаниями

Знания проекта по времени их жизни или актуальности условно делятся на две части: «короткие знания» и «длинные знания». Срок жизни коротких ограничен длительностью проекта, они утратят свою актуальность и значимость после его завершения. Они хранятся в проектной библиотеке, развернутой на платформе Microsoft SharePoint, в форме различных проектных документов.

Срок жизни «длинных знаний» равен сроку жизни информационной системы и исчисляется 8±10 годами. Они хранятся в корпоративной базе знаний на платформе Confluence в виде инструкций по эксплуатации и в форме статей.

Что ж, мы постарались подробно рассказать о том, как устроено управление разными аспектами проекта по внедрению ИСУП. Спасибо, что дочитали до конца. Как и ожидалось, проект получился сложным, но интересным. Он все еще продолжается, хотя де-факто система введена в промышленную эксплуатацию в конце 2021 года. Ну а в заключение хочется поделиться теми выводами, к которым мы пришли, пока внедряли всю эту громадину — вдруг кому пригодятся.

Уроки проекта

А чтобы было веселее, выводы будут в форме рефлексии, положенной на идею стихотворения Владимира Маяковского «Что такое хорошо и что такое плохо».

Будем рады вашим комментариям, и до новых встреч!