Расскажу о том, как я разрабатывал и внедрял в своем отделе гибридную проектную технологию.
Объект исследования, на базе которого я внедрял эту гибридную проектную технологию – это мой отдел «Корпоративные финансы»:
-
его численность свыше 30 человек;
-
в данный момент мы выполняем 11 проектов;
-
общий объем портфеля проектов – свыше 700 миллионов.
В общем, объект исследования достойный.
Все, про что я буду рассказывать, внедрялось на базе компании WiseAdvice IT. Это – компания в группе WiseAdvice, которая занимается оказанием услуг клиентам.
У нас еще есть WiseAdvice Tech, которая работает над внутренней автоматизацией, но сейчас речь не про них, а про заказные проекты.
Проектные технологии: что это, и зачем их разрабатывать?
Вы все знаете, что есть два основных подхода к организации проектной технологии:
-
так называемые гибкие подходы;
-
и предиктивные подходы (их еще называют «водопадными»).
Так вот, сегодня я вам про них рассказывать не буду. Я расскажу, как мы взяли самое лучшее из одного и из второго подхода, внедрили это у себя, и что у нас получилось.
Рассмотрим элементы проектной технологии применительно к оказанию проектных услуг, к внедрению автоматизированных систем:
-
Во-первых, нам нужно понять, как спланировать проект и посчитать план.
-
Во-вторых, нужно понять, какими этапами нам двигаться, какие очереди создания автоматизированной системы выбрать для того или иного проекта. Мы все знаем, что автоматизированная система – это:
-
программный продукт, выбранный для автоматизации;
-
пользователи, которые умеют пользоваться программным продуктом;
-
и инструкции, по которым пользователи используют программный продукт.
-
-
Конечно, нужно понимать, какие работы нужно выполнить внутри каждого этапа.
-
Каким будет результат каждой работы, и как определить требования к этому результату.
-
И, конечно, как это все задокументировать. Не все документы одинаково полезны. На некоторых проектах те или иные виды документов (например, техпроект) могут не применяться. А другие – наоборот, могут быть необходимыми и т.д.
-
И, конечно, это – правила ведения информационной системы управления проектом, которые позволяют отразить результаты деятельности в информационной системе, учитывать результаты работ, помогают понять, как мы движемся по проекту.
Все это в совокупности и есть – проектная технология.
История разработки проектной технологии отдела
Сначала на этом слайде я написал много классных умных слов – оптимизация, повышение эффективности и т.д.
Потом все удалил и написал то, что действительно меня волновало, когда я начинал создавать свою проектную технологию. Меня волновали всего две простые вещи:
-
Как избежать ошибок при вступлении в проект.
-
И как избежать ошибок при его выполнении.
Эти две боли сподвигли меня разработать новую проектную технологию, внедрить в своем отделе и запустить на клиентских проектах.
Конечно, самый простой путь – это путь стандартизации, когда мы к каждому проекту относимся как к стандартному со стандартными этапами. Но в этом случае будет нелегко понять – правильные этапы выбрал руководитель проекта или неправильные.
У меня очень большая личная боль – в день приходит два-три-четыре плана на согласование. Каждое ТЗ, которое мне приходит на вход, содержит по 150-500 страниц. Вдумываться в каждую работу я не могу. И каждый раз анализировать все материалы и сопоставлять план, разработанный руководителем проекта, с этими материалами – нереально.
Можно рассчитывать план для каждого клиента, выбирая уникальный состав работ. А можно брать стандартные планы.
Но мы для всех своих проектов не можем выбрать стандартные планы, потому что мой отдел занимается автоматизацией:
-
бюджетирования,
-
казначейства,
-
РСБУ,
-
управленческого учета,
-
МСФО.
Проекты бюджетирования сотрудники Заказчика начинают планировать летом или осенью. Потому что сами бюджеты чаще всего составляются в октябре или в ноябре – соответственно, к этому времени нам нужно пройти все этапы работ по созданию автоматизированной системы в части планирования.
А план-факт нужен в конце января, если это – месячный план-фактный анализ. Или в конце квартала, если это – квартальный план-фактный анализ.
Следовательно, нам удобнее пройти все этапы и подготовить систему для планирования, а потом спокойно пройти все этапы и подготовить систему для план-фактного анализа.
А в РСБУ наоборот – в РСБУ нужно сделать все, и желательно к 1 января. Можно, конечно, запускаться и в другие периоды – такие кейсы в нашей компании тоже есть, но, как правило, это стрессовые кейсы. Самое удобное – запуститься 1 января и спокойно сдать отчетность.
Т.е. не получается создать один шаблон плана проекта для каждого случая.
В качестве решения я принял модель, где есть стандартные этапы и стандартные группы работ, которые компонуются под конкретную задачу.
Технология называется параметрической, потому что у нас есть параметры проектной технологии, которые определяют то, по какому пути будет выполняться проект.
Какие это параметры?
-
Целостное проектирование (да/нет):
-
либо мы создаем техническое задание, модельный пример, технический проект на все очереди;
-
либо включаем этап проектирования внутрь очереди и очереди компонуем между собой.
-
-
Количество очередей разработки.
-
Количество очередей запуска.
-
Наличие методического проекта (да/нет).
Для примера, если мы говорим, что у нас:
-
количество очередей разработки – 1;
-
количество очередей ввода в действие – 1
Мы получаем простой «водопад».
Но может быть и интереснее ситуация:
-
если у нас количество очередей разработки – 3;
-
а количество очередей ввода в эксплуатацию – 2.
Получается план проекта, который выглядит, как на слайде.
Эту идею я подсмотрел в «1С:Технологии корпоративного внедрения 2.0» (1С:ТКВ) и лучшее применил у себя.
Обзор разработанной технологии
Физически результат моей работы по внедрению проектной технологии представляет собой описанную проектную технологию на базе Confluence (пример на экране).
Когда руководитель проекта начинает новый проект, он копирует пространство, у него получается полностью оформленное проектное пространство со всеми шаблонами документов, со всеми этапами, правилами фиксации требований и правилами построения аналитических отчетов.
Так выглядит структура информационных систем нашего отдела:
-
Microsoft Project мы используем для расчета плана.
-
Confluence используем, чтобы вести документацию, все материалы по проекту, для управления требованиями и построения проектной аналитики.
-
В Jira мы ведем ближайший этап. Jira – классический трекер задач по проекту. Соответственно, все более детальные задачи, чем описаны в Project – они в Jira.
-
И недавно мы еще СППР интегрировали с Confluence, и для управления требованиями применяем СППР.
На слайде показан пример стандартного плана в MS Project.
У меня есть шаблон в MS Project, который использует руководитель проекта. Если проект разбивается по очередям, для него все равно используются элементы этого шаблона, но они компонуются уже в очереди.
Сам этап у нас описывается в Confluence – там хранится документация по этому этапу, все проектные документы, протокол совещаний и т.д.
А детальные задачи ведутся в Jira.
Верхний уровень задач Jira соответствует Project. Т.е., например, когда мы планируем план в Project, мы точно знаем, что нам нужно провести, например, 15 интервью. Но о том, что интервью нам нужно провести с Иваном Ивановичем и Марией Петровной, мы пишем в Jira.
Confluence
Первое, для чего мы используем Confluence – это подготовка документов.
Мы не пишем документы в Word, а потом загружаем в Confluence. Мы делаем наоборот –пишем документы в Confluence и экспортируем их в Word.
Почему это удобно? В Confluence много всяких фишек, например:
-
можно делать отдельные страницы на те или иные разделы документов;
-
его удобно редактировать совместно;
-
можно назначить для пространства глобальные переменные, и они будут подставляться в шаблоны автоматически – у нас все описания в Confluence заполняются таким образом.
Конечно, Confluence выступает как хранилище проектных данных – это протоколы интервью, записи встреч и т.д. Все в одном месте. Когда на проект приходит новый сотрудник, он смотрит записи встреч, протоколы – это позволяет удобно вводить в курс дела нового специалиста.
Еще одно нестандартное применение Confluence – мы его применяем как систему проектной аналитики.
Слева на слайде показан пример статистики по требованиям – сколько требований по каким функциональным областям мы собрали.
А справа – реестр требований, на основании которого статистика строилась.
Confluence настолько удобен для построения таких аналитик, что я применил Confluence даже для подготовки к Инфостарту.
На экране вы видите отчет по подготовке докладчиков секции «Управление проектом».
Основные плагины, которые мы использовали – это:
-
«Свойства страницы»
-
«Отчет по свойствам»
-
«Фильтр таблиц»
-
«Сводная таблица»
Всего четыре плагина. Они очень простые.
Т.е. Confluence – это не просто корпоративная Wikipedia, где мы можем редактировать страницы и загружать информацию.
С помощью плагина «Свойства страницы» мы можем строить статистику. С его помощью мы можем описывать для страниц различные значения свойств, которые потом можно выводить в список.
А по списку уже потом можно строить различные аналитические отчеты с помощью сводных таблиц.
Единственное – мы не смогли сделать простыми плагинами построение матрицы трассировки требований.
Матрица трассировки требований – это когда у нас есть требования, и мы хотим понять, это требования покрыто каким-то проектным решением или для него есть связанное требование на разрыв.
Эту штуку мы не смогли вывести простыми инструментами, вывели их с помощью плагина Table Transformer. Причем Confluence позволяет писать SQL-запрос. По сути, определяя свойства таблицы, вы получаете базу данных, с которой можно работать с помощью SQL-запросов.
Возможности открываются очень широкие, любые аналитические отчеты несложно делать.
Jira
Что касается Jira, я не буду про нее много рассказывать – про нее уже очень много всего говорили.
Единственное, что отмечу – перед тем как использовать Jira, нужно обязательно договориться о типах задач.
У нас в компании Jira использовалась много лет. Там когда нажимаешь «Тип задачи» – вываливается список на два экрана. Сотрудники проектных отделов в этом путались, было непонятно, какой конкретно тип задачи указать:
-
я взял всего семь типов;
-
описал, на каком этапе проекта какой тип и как применяется;
-
и главное, отметил, кто может вводить задачу такого типа – тогда все стало прозрачно и очевидно.
Когда мы спланировали проект, но еще не понимаем всех детальных задач, мы в Jira используем плагин, который называется «Структура» – он позволяет делать дерево как в Project.
И когда мы заключаем дополнительное соглашение на следующий этап работ, мы верхнеуровневые задачи, которые будем выполнять, тоже нарезаем в Jira.
Кто-то может задать вопрос – почему бы сразу не составлять план проекта в Jira? Потому что Jira – это веб-интерфейс, и это дольше, чем в Project. В Project быстрее получается. А во-вторых, у Project более интересные инструменты для балансировки ресурсов, для проверки сбалансированности планов.
Но в Jira классно сделан план-факт. Поэтому мы используем два инструмента.
-
Сильные стороны Project мы используем для планирования.
-
Сильные стороны Jira используем для план-фактного анализа.
Плагин «Структура» может показаться сложным, но справа на слайде показано, как он настраивается. Мне тоже сначала показалось сложным, но я за пару часов справился и сделал всю структуру, которая мне нужна для работы.
Интеграция с СППР
Что касается СППР – ситуация такая, что в веб-интерфейсе Confluence, мы на каждое требование делаем отдельную страницу. И пока страница загружается, сохраняется, теряется определенное время.
Так работать не очень удобно, в отличие от СППР, где можно просто сделать табличный документ и в табличном документе редактировать эти требования.
Поэтому, чтобы работать с требованиями, мы прикрутили к Confluence СППР. Требования вводим в СППР, и они автоматически в Confluence экспортируются. И наоборот.
Интегрируется очень просто. Интеграцию я сделал в качестве хобби за выходные, чтобы проверить свою гипотезу, что 1С можно интегрировать с Confluence по API.
Если кому-то интересно – вот, пожалуйста, готовый кусок кода. Пробуйте, интегрируйте.
Параметрическая настройка технологии под особенности будущего проекта
Внутри проекта мы выделили минимальный значимый результат работ для клиента.
-
Модель AS IS – описание как есть.
-
Модель TO BE – схема функциональной структуры как должно быть.
-
Требования пользователей,
-
Модельный пример – описание того, как это может быть сделано в системе. С оговорками, что типовая сейчас нам это не позволяет, но мы ее доработаем.
-
Требование на функциональный разрыв.
-
Проектное решение – как будет выглядеть процесс после выполнения всех доработок.
-
Техническое решение – описание конкретной доработки – документа или интеграционного механизма.
В верхней части слайда приведено три разных схемы:
-
Первая – это классический «водопад».
-
Второй вариант – это маленький «водопад», когда мы объединяем техническое проектирование и разработку техзадания.
-
Третий вариант – это когда мы работаем по очередям.
Вне зависимости от того, какую схему выполнения проекта выбрал руководитель, набор минимальных значимых результатов, который получит заказчик, одинаков.
Таким образом, аналитики выполняют одну и ту же работу, но в зависимости от того, какую схему выполнения проекта выбрал руководитель, она может по-разному документироваться.
На слайде представлен пример того, какие модели мы строим на основании каких требований, и как они могут документироваться.
Ключевые результаты каждого из этапов
Немного расскажу про результаты каждого из этапов работ.
Первое – я считаю, что описание модели AS IS – это просто слив бюджета, ненужная работа, потому что пока вы их описываете, они могут поменяться, а во-вторых, для заказчика ценности в описании этой модели немного.
Модель AS IS по моему глубокому убеждению нужна подрядчику для ввода нового специалиста в курс дела, чтобы он понимал объект автоматизации, понимал, из каких предпосылок были выбраны те или иные проектные решения.
Чтобы построить хорошую модель AS IS, нужно правильно оформлять протоколы интервью.
Кто-то может подумать – что там протоколы писать? Мы поговорили и записали.
Когда я коллег учил, мы сделали такое упражнение – мы взяли первый попавшийся протокол интервью и начали раскладывать его в ту структуру, которую я предлагаю – в таблицу. И сразу стало видно, что в протоколе есть упущения, потому что по одному из шагов не был описан выходной результат.
Поэтому, когда мы делаем протокол интервью, очень классно использовать такие структурированные шаблоны, чтобы ничего не упустить.
Здесь показан пример страницы требования.
На подчиненные страницы в Confluence мы пишем все требования, которые собрали. А с помощью плагина «Отчет по свойствам страницы» формируем протокол интервью – собираем в единый реестр все требования, которые в рамках этого протокола были собраны.
И также автоматизированно получаем полный перечень функциональных требований, которые будем потом использовать для автоматизации.
Модель TO BE – это схема функциональной структуры, которая описывает, какой процесс каким образом будет автоматизирован.
А что касается модели AS IS – при правильно оформленных протоколах вы просто их немного переформатируете и получаете модель AS IS. Не нужно делать двойную работу. Правильно оформляя протоколы, вы убиваете сразу двух зайцев.
Требования на разрывы, проектные и технические решения
Требования на разрывы – это второй уровень требований, который мы используем в своей работе.
В нашей технологии два уровня требований.
-
Первый – это пользовательский уровень требований, которые мы собираем в рамках протоколов.
-
И второй уровень требований – это требования на разрывы, которые выявляются по итогам моделирования и уточняют пользовательские требования. Либо может быть выявлен разрыв, который ранее в пользовательских требованиях не был, но при моделировании его увидели. Т.е. аналитик демонстрирует пользователю систему на данных пользователя (не на данных стандартной демобазы). Это позволяет проверить, что система работает так, как нужно пользователю. А там, где она работает так, как не нужно пользователю, регистрируется требование на разрыв.
Кроме того, разрывы бывают еще и организационными, когда заказчик хочет какой-то отчет, а нет человека, который данные для этого отчета собирает.
Проектное решение – то, что готовится в рамках разработки технического задания. Т.е. техническое задание – это набор проектных решений.
-
Во-первых, это описания процессов TO BE – как будет выглядеть процесс.
-
Это описание шагов.
-
Требования к объектам автоматизированной системы, поддерживающих этот процесс.
Для моделирования процесса TO BE мы разработали очень интересное решение – мы взяли практически стандартный BPMN, но сделали небольшое добавление.
-
Красные объекты – это объекты новые.
-
Желтые объекты – это объекты с доработками.
-
Зеленые – это типовые.
Посмотрев на такую схему процесса, вы сразу можете понять, насколько процесс ложится или не ложится на типовое решение.
Техническое решение описывает конкретную доработку – либо интеграционный механизм, либо какое-то изменение – например, обработку для нормализации.
Понятно, что в техническое решение входит стандартный набор пунктов, уже привычный для отрасли – это
-
Прототипы интерфейсов
-
Перечни реквизитов и т.д.
-
Но здесь мы тоже придумали интересную штуку – мы на UML моделируем взаимодействие объектов метаданных между собой и описываем функции, которые есть у этих объектов и влияние этих функций на другие объекты. Она очень здорово помогает упростить взаимодействие разработчиков и аналитиков. Когда аналитик такую схему делает, он начинает задумываться, на что повлияет то или иное изменение.
-
И, конечно, сценарий функционального тестирования. Обязательно в техрешении пишем, как мы будем проверять, что доработка выполнена корректно.
ИТ-поддержка технологии управления проектом. Два бэклога
И самое интересное – это как выглядит процесс разработки.
Мы используем два бэклога.
Почему два? Представьте, что есть навороченный металлический робот с шипами, который плюется огнем и стреляет металлическими пульками. Ребенок захочет такой? Скорее всего, захочет – классный же. А родители захотят купить своему ребенку такую игрушку? Вряд ли, опасно же.
А если робот будет весь зализанный, безопасный, плюшевый – родители захотят такого купить? Да, ведь он безопасный. А ребенку это будет интересно? Вроде не очень.
Это – классическая проблема, которая выявляется при создании автоматизированной системы.
То же самое – представим себе прайс-лист с перечнем цен. Если пользователю нужно забивать каждую строку в регистр сведений, пользователю это понравится? Вряд ли. Будет саботировать процесс.
А если пользователь хочет обработку, которая сама ходит по сайтам всех конкурентов, собирает цены, загружает – пользователь будет счастлив? Конечно, будет. Но стоимость такой разработки довольно высокая. И бизнес тут не будет счастлив.
И нужно искать баланс – чтобы, с одной стороны, разработка стоила разумных денег, с другой стороны, позволяла пользователю выполнять свои функции эффективно без лишней ручной работы.
Поэтому мы используем два бэклога:
-
Первый бэклог – это бэклог проектных решений, т.е. процессов.
-
Второй бэклог – это бэклог доработок.
Когда мы начинаем планировать спринт, мы берем самое рисковое и самое сложное проектное решение. Потому что чем больше рисков мы снимем в начале разработки, тем с большей вероятностью мы завершим все успешно.
Берем самое рисковое проектное решение и выбираем все технические решения, все доработки к этому бизнес-процессу, которые нужны, чтобы это проектное решение запустить.
Выполняем разработку – в первом спринте мы выполняем первое техническое решение, по результатам спринта проводим демонстрацию заказчику.
В чем ценность Agile? Это постоянная обратная связь. Даже если процесс еще не закончен, мы показываем доработку, во втором спринте в этом примере мы выполнили все технические решения, необходимые для запуска первого процесса. И в конце второго спринта мы показываем доработки и показываем весь процесс в сборе.
Получилось, что первые этапы – это, фактически, формирование бэклога. Так называемый «нулевой спринт».
Сама разработка – классический итерационный процесс разработки по сформированным бэклогам.
А что касается ввода в действие, опытной и промышленной эксплуатации, там мы ничего нового не придумали. Там стандартный набор документов:
-
Программа методика испытаний;
-
Дополнение к документации и т.д.
Все самые инновационные изменения у нас как раз в части сбора требований, формирования бэклога и выполнения разработки.
Внедрение технологии
Пару слов о том, как я внедрял эту технологию.
Чтобы внедрить технологию управления проектом с помощью Confluence, я использовал Confluence.
-
В Confluence описана вся технология в виде вебинаров – получился курс по проектной технологии.
-
Когда сейчас ко мне выходит новый специалист, он в течение двух-трех дней смотрит курс, потом сдает экзамен с помощью Confluence – в нем есть плагин «Квизы».
-
И только после этого мы его допускаем до проекта.
Кроме этого, я сделал так, чтобы коллегам было удобно использовать новую проектную технологию. Т.е. все шаблоны детально описаны. На самом деле, если брать техническое задание, там достаточно просто ставить параметры под конкретного клиента. Весь шаблон написан, а сутевая часть технического задания – проектные решения – они цепляются к техническому заданию вложенными страницами. Но с помощью макроса «Включить страницу» они включаются в документ, и у нас получается единый целый документ, хотя физически в Confluence он выглядит как дерево.
И фишка Confluence в том, что когда у нас каждое проектное решение отдельной страницей, мы можем отслеживать для каждого проектного решения его жизненный цикл. Проверять – в разработке оно или не в разработке, возможно, оно отклонено заказчиком и т.д.
Самое интересное, что в процессе внедрения коллеги очень вовлеклись и начали предлагать постоянные улучшения – получилась живая проектная технология, которая постоянно сама себя развивает.
Планы и достижения
Что касается ближайших планов:
-
Мы хотим более тесно интегрировать СППР с Confluence, потому что на каждом втором крупном корпоративном проекте заказчики хотят одновременно с Confluence использовать СППР. На данный момент у нас работает интеграция в части требований. Интеграция в части других объектов у нас сейчас в разработке.
Предполагается, что в схеме интеграции:-
проектное решение будет преобразовываться в функцию;
-
техническое решение – в техпроект. Но возможно, что-то поменяется. Об этом мы еще подумаем в ближайшее время.
-
-
Ввиду того, что в результате проекта мы оперируем минимальными значимыми результатами для заказчика (эти два бэклога – бэклог из проектных решений и бэклог из технических решений), логично дальше подумать об Agile-проектах. Для них как раз характерно использование таких PBI (Product Backlog Item) – небольших элементов бэклога, которые понятно, как реализовывать, понятно, как оценивать. В общем, дальше логично посмотреть в сторону Agile.
Теперь о достижениях, которые можно оценить:
-
Я стал намного меньше времени тратить на согласование планов, потому что пакеты работ в планах используются стандартные, а их состав описывается параметрами. Поэтому на проверку планов я стал тратить намного меньше времени без потери качества этой проверки.
-
Использование проектных и технических решений упорядочило работу на проекте. С ними наглядно видно, насколько проект эффективно продвигается или отстает. Потому что если мы начали этап проектирования, и в первую неделю аналитик не может согласовать проектное решение, это уже знак, что мне нужно подключиться, чтобы разобраться, что там на проекте происходит. Понятно, сколько времени нужно выполнять эти маленькие элементы в виде ПР и ТР, и, если эти работы отстают, это намного проще отследить.
|
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere. Больше статей можно прочитать здесь. Приглашаем на мероприятия Инфостарта 2023 года:
|
