CC BY
10
БОТ: 10.15587/2312-8372.2017.118443
РАЗРАБОТКА СТРУКТУРЫ И СОДЕРЖАНИЯ 8СЯиМ-ТЕХНОЛОГИЙ УПРАВЛЕНИЯ БЫСТРОТЕКУЩИМИ МЕДИЦИНСКИМИ
ПРОЕКТАМИ С КРИТИЧЕСКИМИ РИСКАМИ
Становская И. И., Хеблов И. А. А., Гурьев И. Н., Кошулян С. В.
1. Введение
БСКиМ-технологии впервые появились в ГГ-сфере, в основном, при реализации проектов создания компьютерных программ. Но существуют и другие проекты, в которых SCRUM-технологии являются чуть ли не единственным способом достичь желаемой цели.
К БСЯиМ-технологии управления проектами прибегают чаще всего в том случае, когда проект имеет следующие свойства.
- он имеет на порядки меньшие сроки, чем «обычные» проекты;
- Команда проекта значительно меньше структурирована: все умеют всё и могут быть привлечены к выполнению любого этапа проекта;
- менеджер проекта находится внутри такой Команды и работает на уровне других членов Команды;
- этапы выполнения проекта, которые в SCRUM-технологиях называются Спринтами, подвергаются уточнению после завершения предыдущего этапа с определением качества их выполнения и оглядкой на достижения миссии и целей проекта в целом.
В некоторых случаях к этим факторам добавляется высокая рисковая опасность, которая сопровождает проект. При этом оба фактора риска - вероятность наступления и стоимость рисковых потерь - находятся на очень высоком уровне. В работе такие проекты называли «быстротекущими с повышенной рисковой опасностью и строгой ответственностью за результаты их выполнения». Наиболее яркими представителями таких проектов являются медицинские, в частности, хирургические операции.
Актуальность работы в данном направлении определяется также тем, что хирургические операции постоянно усложняются за счет применения современных приборов и инструментов, управлять которыми без современных информационных технологий становится все сложнее. Управление такими операциями как проектом на основе БСКиМ-технологий позволяет предвидеть больший процент рисков, оперативно предупреждать и противодействовать им.
2. Объект исследования и его технологический аудит
Объект исследования - это проект, который, сохраняя все основные свойства проекта (уникальность, ограниченность во времени, экономических и материальных ресурсах, выполняющийся Командой проекта с заданной целью во взаимодействии с турбулентной окружающей средой), имеет ряд специфических особенностей. Данные особенности позволяют выделить управление проектом в особый класс проектной деятельности.
Прежде всего, - это быстротекучесть проекта. Если «обычные» проекты, например в строительстве, могут длиться годами, то продолжительность быстротекущих проектов, как правило, ограничивается часами, а иногда - минутами. Поэтому неправильный выбор структуры и содержания проекта на всех этапах его реализации может иметь необратимые последствия.
Во-вторых, - это высокая ответственность за результат проектной деятельности. Где бы ни выполнялись такие проекты, - в энергетике, на транспорте, в процессе борьбы с чрезвычайными ситуациями, - как правило, их миссией является сохранение человеческой жизни.
Третьей особенностью рассматриваемых проектов является повышенный по сравнению с обычными уровень рисковых событий, сопровождающий проект. В подобных проектах чаще всего встречаются латентные, неожиданные риски, которые невозможно предвидеть заранее. Поэтому меры по их недопущению или компенсации их последствий приходится принимать в кратчайшее время в процессе проектной деятельности, используя все имеющиеся в наличии ресурсы.
Ярким примером такой проектной деятельности является медицинская хирургическая операция, которая содержит все описанные выше процедуры и, безусловно, является быстротекущим проектом с высокой степенью риска и ответственности. Здесь проектный подход является инновационным содержанием операции, а SCRUM-технологии - современной и единственно доступной в этих условиях формой ее осуществления.
С другой стороны, подобный подход является революционным, - он нигде ранее в мировой практике не применялся, что усложняет выполнение сравнительного анализа. Из-за этого можно ответить на вопрос, как это было в медицине до применения проектного подхода к операциям, и нельзя, - как такой подход работает у других специалистов в области проектного менеджмента.
Одним из наиболее проблемных мест в объекте исследования является вынужденная необходимость в перераспределении ролей всех участников проекта. Команда проекта должна быть относительно немногочисленной, а значит, -мобильной и многофункциональной. Владелец продукта проекта, если это - пациент в операционной, является одновременно самым заинтересованным лицом в успешном завершении проекта и самым «отстраненным» от принятия каких-либо решений в выборе структуры и содержания проектных технологий.
3. Цель и задачи исследования
Цель исследования - повышение эффективности проактивного управления быстротекущими проектами с критическими рисками путем повышения качества продукта проекта за счет разработки и внедрения методов реализации SCRUM-технологий управления структурой и содержанием проектной деятельности.
Для достижения этой цели необходимо решить следующие задачи:
1. Разработать концепцию планирования и управления отдельными этапами (Спринтами) проекта.
2. Разработать систему поддержки принятия решений в проактивном управлении структурой и содержанием операций в хирургической медицинской практике на основе SCRUM-технологии.
3. Выполнить практическое испытание системы и оценить эффект от ее испытаний.
4. Исследование существующих решений проблемы
В последние годы проектное управление приобрело весьма большое распространение, потому что оно позволяет постоянно «находиться рядом» с процессом, предвосхищая возможные проблемы в течение последнего и устраняя последствия возникающих при его осуществлении рисков. Однако не все процессы могут под таким управлением осуществляться, так как они не укладываются в существующие рамки понятия «управление проектом».
В частности, проблемы возникают при управлении быстротекущими, но, в то же время, очень ответственными процессами. К последним относятся процессы, осуществляемые относительно небольшим коллективом многофункциональных исполнителей. Среди основных направлений устранения этих проблемы, выявленных в ресурсах мировой научной периодики, могут быть выделены:
- SCRUM-технологии управления проектами, включающие жесткое разделение всего процесса на отдельные этапы (Спринты) [1-5];
- новые роли участников Команды проекта в планировании и выполнении работ на отдельных Спринтах [6-8];
- принятие решения о дальнейших действиях после завершения каждого Спринта с учетом всех предотвращенных и выявленных на предыдущих Спринтах рисков [11-15].
В частности, работа [1] посвящена технологии SCRUM-процессу, который включает набор методов и предварительно определенных ролей. SCRUM естественным образом (который следует из содержания проекта) распределяется на Спринты - своеобразные законченные подпроекты [2]. В течение каждого Спринта (продолжительность которого определяется Командой), Команда проекта обеспечивает функциональный рост продукта проекта.
Примером таких проектов могут быть проекты создания программного продукта [3], поддержки безопасности на суперсооружениях [4], например, ядерных объектах или реагирования на чрезвычайные ситуации в последних [5]. Сюда можно отнести также проекты восстановления поврежденных узлов и агрегатов транспортных средств во время движения, проектов медицинского вмешательства в организм человека, и тому подобное.
Авторами [6] показано, что во всех этих примерах Команда проекта относительно невелика и, несмотря на то, что ее участники имеют узкую специализацию, вынуждена выполнять все работы проекта почти общим коллективом. Например, в течение хирургической операции анестезиолог не «идет домой» после завершения анестезии, а на равных продолжает свою активную присутствие почти во всех Спринтах до полного завершения активной фазы операции [7].
Набор свойств, которые имплементируются в каждом Спринте, определяется документом под названием product backlog (документация запросов на выполнение работ), который имеет самую высокую приоритетность по уровню требований к выполняемой работе. Однако, как следует из работы [8], эту приоритетность не всегда легко установить. Например, в случае медицинского вмешательства, наивысшим приоритетом, безусловно, обладает жизнь челове-
ка. Однако последовательность Спринтов, ведущая к сохранению и повышению качества жизни, не всегда очевидна. В этом случае необходимо выявить и проанализировать все риски на пути к конечной цели и по ним определить структуру SCRUM-технологии и содержание всех ее Спринтов.
Еще одно важное противоречие следует из анализа работ [9, 10]. Дело в том, что запросы на выполнение работ (backlog items) определяются в течение совещания по планированию каждого Спринта (sprint planning meeting). В течение этого совещания Владелец продукта должен информировать о задачах, которые он хочет, чтобы были выполнены. Во время хирургической операции все не так. Владелец продукта под наркозом и, в лучшем случае, что-то определить могут его родственники. Остается Команде проекта самой определить, сколько они могут сделать, чтобы завершить необходимые части процесса в течение следующего Спринта.
Другим общим свойством в приведенных примерах является то, что начало проекта инициируется некоторым «предрисковым» событием. К ним относятся нарушения технологического процесса и систем безопасности, недопустимое изменение параметров работы агрегатов технических систем, заболевания человека и тому подобное [8].
Как отмечают авторы [1, 2], в «классической» SCRUM-технологии планирование Спринтов (Sprint Planning Meeting) происходит в начале каждого нового Спринта. При этом считается, что во время выполнения Спринта задачи Команды проекта не изменяются. Но в случае критических рисков это не всегда соблюдается, ведь некоторые риски во время реализации Спринта могут привести к его изменению до полной остановки и/или замены [11]. Ведь в этом случае даже начало проекта может совпадать по времени с началом кризиса или находится в пределах его развития (ургентное реагирование), а может происходить позже, когда наступят благоприятные условия (плановое реагирование). В последнем случае сохраняется надежда, что процессы проекта будут проходить в более благоприятных условиях.
Например, Команда проекта (группа хирургов определенного профиля) начинает операцию и определяет, что первичный диагноз был поставлен неправильно, а значит, дальнейшее хирургическое вмешательство требует специалистов совершенно другого профиля [12, 13]. Такие риски должны сопровождаться серьезным анализом всей Команды и корректировкой структуры и содержания дальнейших работ [14, 15].
Таким образом, результаты анализа позволяют сделать вывод о том, что применение SCRUM-технологии в управлении проектом хирургической операции представляется весьма перспективным. Однако для этого необходимо разработать новые методы адаптации структуры и содержания SCRUM-технологий управления быстротекущими медицинскими проектами к критическим рискам, сопровождающим этот процесс.
5. Методы исследования
Новые методы, использованные в данном исследовании, вытекают, прежде всего, из упомянутого выше совершенно нового распределения ролей в SCRUM-технологии управления проектом «хирургическая операция», по срав-
нению с существующими. Посмотрим еще раз на традиционное распределение ролей в SCRUM-технологиях [9].
SCRUM-мастер - проводит совещания и следит за соблюдением всех принципов SCRUM, разрешает противоречия и защищает Команду проекта от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения SCRUM-процесса.
Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве SCRUM-мастера.
Владелец продукта - человек, который имеет непосредственный интерес в качественном конечном продукте, он понимает, как этот продукт должен выглядеть [10]. Этот человек не работает в Команде проекта, он работает на стороне заказчика/клиента, но этот человек работает с Командой. И это тот человек, который расставляет приоритеты для задач.
Команда проекта - многофункциональная команда разработчиков и исполнителей проекта, состоящая из специалистов разных профилей: например, хирурги, манипуляционные и операционные сестры, инженеры, анестезиологи, лаборанты и т. д. Размер Команды в идеале составляет от 3 до 9 человек. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме Команды, не может вмешиваться в процесс разработки на протяжении Спринта.
Пользователи:
Клиенты, Продавцы - лица, которые инициируют проект, и для которых проект будет приносить выгоду. Они вовлечены в SCRUM только во время обзорного совещания по Спринту.
Управляющие - люди, которые управляют персоналом.
Эксперты-консультанты :
В случае, когда конечным продуктом является здоровье человека, трудно классифицировать место пациента в приведенном выше списке ролей. Очевидно, что ближе всего он к Владельцу продукта, т. к., безусловно, «имеет непосредственный интерес в качественном конечном продукте». Но этот человек не «работает с Командой проекта», разве что, опосредовано - через объективные показатели своего состояния. Эта, совершенно новая в SCRUM-технологиях роль в корне меняет расстановку сил во время выполнения проекта хирургической операции (рис. 1). Частично эта роль передается Менеджеру проекта, а частично, - условным «Родственникам», курирующим операцию извне.
Второй важнейшей особенностью SCRUM-технологии управления проектом «хирургическая операция» является ее очевидная быстротечность, на порядки превышающая скорость традиционных, даже при том, что эти традиционные технологии позиционируются как скоростные [8].
8СЯИМ-мастер
Акционеры
ЗСБШМ- / Руково-
# Владелец мастеР дитель
продукта
Родственники
Пациент
Рис. 1. Распределение ролей во время реализации SCRUM-технологии управления «обычным» проектом (1) и проектом хирургической операции (2)
В сочетании со значительными рисками и высочайшей ответственностью, это усложняет обычные методы исследования БСЯиМ-технологий, привлекая к ним существующие в медицине методы статистических сравнительных экспериментов над значительным количеством пациентов [13].
6. Результаты исследования
6.1. Концепция планирования и управления отдельными этапами (Спринтами) проекта
Спринт начинается с анализа текущего состояния параметров объекта [12]. Далее из списка того, что должно быть реализовано, выбираются задачи, обязательства по выполнению которых принимает на себя Команда. На основе выбранных задач создается функциональность работ Спринта. Все функции разбиты по задачам, каждая из которых оценивается Командой. Команда постоянно, с учета рискового окружения, оценивает объем работы, который необходимо провести для завершения задачи. При реализации #-го Спринта происходит своеобразное преобразование информации: входная «перерабатывается» в выходную с помощью выполненных Командой работ и под влиянием внутренних и внешних рисковых событий, которые имели место.
Переработку информации, то есть непосредственно работу, выполняет Команда проекта, которая в SCRUM-технологиях совмещает также менеджерское сопровождение последнего (рис. 2).
Внутренние и нешние рисковые события
Спринт N
Рис. 2. Схема «преобразования» информации во время управления промежуточным Спринтом
Примером такой информации в медит не может быть набор объективных постоянно измеряемых параметров человека-пациента (температура, давление, частота пульса и другие характеристики кардиограммы, компоненты крови и т. д.).
В авиации это температура и давление в различных зонах двигателя, расход и остаток топлива, высота и скорость полета, параметры воздуха в салоне.
Как видно из схемы, приведенной на рис. 2, три главных фактора определяют ход и результат выполнения работ на каждом Спринте, а, следовательно, и на проекте в целом:
- профессионализм выполнения работ Командой проекта;
- рисковые события, которые сопровождают проект;
- менеджерское сопровождение (управления) проектом.
Первый фактор относится к профессиональной деятельности членов Команды проекта; остается надеяться, что квалификация членов Команды максимально соответствует наложенным на нее функциям. При серьезных ошибках в этой сфере их можно идентифицировать как риск и отнести ко второму фактору (рис. 3).
I»
Рисковое событие, которое возникло в результате непрофессиональных действй членов Команды проекта
Рис. 3. Перемещение факторов «профессионализма» к группе факторов риска
Второй фактор - риски проекта. В работе их рассматривали с двух сторон: риски, которые не вылились в рисковые события (например, риск остановки сердца), и рисковые события, которые произошли (например, внеплановое кровотечение) и которые нуждаются в их компенсации. Первые оценивали в параметрах вероятности, а вторые - в медицинской и финансовой «стоимости вопроса».
Третий фактор - менеджерское сопровождение или, собственно, управление проектом рассмотрим на микро- (отдельные Спринты) и макро- (проект в целом) уровнях как дальнейшее развитие известной методологии PDCA [16]. Для этого представим последовательность стадий управления Спринтом в виде циклической диаграммы АММД «Анализ» - «Метод» - «Модель» - «Действие» (рис. 4).
«Классический» цикл Шухарта — Деминга
Цикл Шухарта — Деминга для текущего спринта
Рис. 4. Цикл стадий текущего Спринта общей БСЯиМ-технологии проактивно-
го управления быстротекущими проектами
Цикл стадий текущего Спринта является полным, если соответствующий Спринт не заканчивается его прерыванием. Такое прерывание может осуществляться, по крайней мере, в трех случаях:
- после начала работ текущего Спринта выясняется, что эти работы выполнять не нужно (например, после оперативного доступа оказывается, что первичный диагноз был поставлен неверно, или оперативное обстановка не со-
ответствует предполагаемой);
- после начала работ текущего Спринта выясняется, что для достижения его цели или цели всего проекта необходимо срочно выполнить дополнительные, не предусмотренные планом, работы;
- до завершения работ текущего Спринта закончился:
S оперативный запас материалов (донорской крови, лекарств, перевязочных и т. д.);
S средств на приобретение этих материалов, электроэнергии или информации о преодолении неожиданных кризисов, которая может содержаться в литературе, в Интернете или в опыте других нужных специалистов, которые могут находиться на другом конце земного шара.
В любом случае, после прерывания работ текущего Спринта снова выполняется анализ информации, поступившей от сложившейся ситуации, и принимается решение, к какому Спринту: плановому или не предусмотренному планом необходимо сделать переход, или прекратить выполнение проекта вообще.
Анализ (Check) предусматривает обработку информации, поступившей от предыдущего Спринта (от расчетов до «мозгового» штурма»), определение главных направлений дальнейшего развития проекта и предотвращения латентных рисков с тяжелыми последствиями.
Далее подбираются (или создаются новые) модели и методы развития событий. Команда проекта рассчитывает вероятности достижения целей текущего Спринта, обсуждает побочные явления и «сюрпризы», которые могут настигнуть проект. Затем принимается окончательное решение и выполняются действия, составляющие содержательную сущность текущего Спринта.
На этом цикл «Анализ» - «Метод» - «Модель» - «Действие», а с ним и текущий Спринт завершаются, и осуществляется переход к следующему Спринта. При этом важной задачей является корректировка структуры SCRUM-технологии и определения Спринта, к которому необходимо осуществить переход.
Далее рассмотрим анализ результатов предыдущих Спринтов в управлении Спринтами SCRUM-технологий. В начале каждого нового Спринта осуществляется новый анализ ситуации, результаты которого могут существенно отличаться от запланированного в начале выполнения проекта в целом.
Ведь по закону С. Д. Бушуева, креативная составляющая судьба любой проектной деятельности не может опускаться до нуля, поскольку турбулентная окружающая среда, в которой эта деятельность осуществляется, всегда этому мешает [17].
Жизненный цикл любой SCRUM-технологии начинается с планирования ее хода, а также по планированию необходимых для осуществления этой технологии работ. В процессе такого хода, в зависимости от сложности продукта проекта, под влиянием турбулентной окружающей среды увеличивается доля креативной проектной деятельности.
Соответственно, турбулентная окружающая среда делает каждый проект, который осуществляется по SCRUM-технологии, уникальным, то есть предоставляет ему одну из главных признаков проектной деятельности.
Когда же речь идет о сложном проекте, доля креативной составляющей становится весьма значительной. В первую очередь, это объясняется тем, что во
время выполнения такого проекта успевают произойти рисковые события. Поэтому одним фактором, рост которого приводит к увеличению доли креативной проектной деятельности, является время выполнения проекта.
Может показаться, что для быстрых процессов такая доля невелика, ведь большинство рисковых событий просто не пройдет. Однако высокая вероятность каждой рискового события и сверхвысокая цена ее последствий (вспомним те же хирургические операции) «работают» в другом направлении, существенно увеличивая креативную часть.
С другой стороны, если SCRUM-технология предусматривает выполнение однотипных Спринтов, судьба креативной доли может, наоборот, уменьшаться [18].
Когда происходит воздействие на состояние выполнения SCRUM-технологии более чем одного, или даже всех факторов, речь может идти о синергетическомv сочетании результата действия последних. В этом случае отдельные факторы, которые действуют на процесс осуществления проекта, усиливают или ослабляют друг друга, и их суммарное воздействие оказывается больше или меньше суммы их отдельных воздействий [19].
6.2. Принятие решений в проактивном управлении операцией на основе SCRUM-технологии
Проактивный менеджмент структурой SCRUM-технологий управления быстротекущими проектами с критическими рисками имеет целью поддержку такого уровня прогнозной вероятности достижения поставленной цели, которая обеспечит это достижение с минимумом потерь.
Любой путь, избранный под влиянием любой прогнозной модели, к сожалению, не гарантирует стопроцентный успех, но стратегия двигаться вдоль пути с наибольшей прогнозной вероятностью выглядит наиболее перспективной.
Рост времени выполнения проекта может быть связан с турбулентной окружающей средой, влияние которой замедляет процесс. Замедление может быть доведено до полного прекращения проекта. В последнем случае речь может идти о возвращении к такому проекту позже (например, перенос операции). Будем считать этот случай одним из вариантов восстановления продукта проекта, поскольку его запоздалое выполнение уже не может осуществляться по первичным проектам и планам. Действительно, на новом этапе в наличии уже есть новые материалы, техника, технология, человеческие ресурсы, материальное обеспечение и т. д., и все это требует новой инженерной или медицинской поддержки: новых элементов и новых технологий.
Таким образом, в работе под восстановлением вообще понимали или непосредственное текущее восстановление или обновление продукта проекта через некоторое время, которое невозможно без изменения первоначального плана и технологий проектной деятельности. При этом предполагается, что в начале второго вида восстановления многое меняется по сравнению с началом первичного восстановления (рис. 5).
Рис. 5. Изменение проектного турбулентного окружения в начале восстановления продукта проекта
Эти изменения не всегда очевидны, они не лежат на поверхности. Для их выявления необходимо вновь проанализировать окружающую среду. Ведь за время простоя могли существенно измениться имеющиеся лекарства, поставщики, оборудование, исполнители, законодательство и т. д. Необходимо также заново оценить общее состояние пациента и текущие функциональные особенности его органов.
При такой оценке менеджера проекта восстановления, как правило, могут ожидать «большие неожиданности», - которые в терминах управления проектом, безусловно, является рисками. Эти рисками не обычные [17], а неожиданные, которые имеют весьма опосредованное отношение к окружающей среде [18, 19].
Под структурой SCRUM-технологий будем понимать такие объекты:
- множество Спринтов, включая технологии и функциональные связи между ними;
- множество работ в проекте, потребляющих различные ресурсы и пути доставки последних.
Типичная (плановая) структура Спринта SCRUM-технологии управления проектом «хирургическая операция» приведена на рис. 6.
Во время выполнения каждого Спринта может произойти событие, которое Командой проекта воспринимается как сигнал о том, что вероятность некоторого кризисного события резко возросла. Напомним, что речь в работе идет о проактивном управлении проектом.
В этом случае возможна одна из перечисленных действий Команды проекта или любое их сочетание.
1. Не вносить какие-либо изменения в первоначальный план.
2. Выполнить дополнительную работу в пределах текущего Спринта и дальше перейти к следующему (по плану на проект) Спринту.
3. Добавить новый (не предусмотренный первоначальным планом) Спринт, после выполнения которого перейти к следующему плановому Спринту.
4. Полностью изменить плановый набор Спринтов, идущих после текущего.
5. Прекратить выполнение проекта и выйти из него через Спринт завершения.
Хирурги ч^У Манипуляционные сестры
Операционные сестры Инженеры
Анестезиологи Лаборанты
Рис. 6. Структура SCRUM-технологии управления проектом «хирургическая операция»: sprint 1 - предварительная подготовка больного, анестезия; sprint 2 - оперативный доступ; sprint 3 - оперативный прием; sprint 4 - текущие
анализы; sprint 5 - обработка операционного поля; sprint 6 - биопсия; sprint 7 - оперативный выход; sprint 8 - интенсивное наблюдение (реанимация); sprint 9 - палатное наблюдение (реабилитация)
Конкретное действие (или их сочетание) выбирают по вероятности достижения главной цели проекта. Эти вероятности вычисляют по моделям соответствующих действий или «назначают» экспертным советом Команды проекта.
Как следует из опыта хирургических вмешательств, одной из важнейших характеристик, по которой можно оценивать эффективность медицинского SCRUM-проекта, является время. Естественно, что при этом должны сохраняться или даже улучшаться медицинские характеристики операции. Речь идет о сохранении жиз-
ненных показателей организма больного (температуры, давления, частоты сердцебиения) в пределах допустимой нормы. Кроме того, должны впоследствии улучшаться относительно контрольной группы больных, для которых SCRUM-технология управления проектом «хирургическая операция» не применялась.
Скорость операции в целом зависит от скорости отдельных Спринтов, а остальные - заложники многих рисков, с которыми сталкиваются процесс, как со стороны пациента, так и со стороны хирургической бригады, внешних связей, фармацевтического обеспечения, медицинской аппаратуры и тому подобное.
Главное отличие управления проектами от этого механизма является то, что после каждого этапа в плановом порядке и в любой момент времени при чрезвычайной ситуации осуществляется экстренный переход к подсистеме итерационного планирования содержания SCRUM-технологий (рис. 7).
Рис. 7. Изменения последовательности Спринтов в SCRUM-технологии управления быстротекущими проектами: 1 - отсутствие изменений в предварительном плане выполнения SCRUM-технологий; 2 - добавление нового Спринта (Спринт Д) к цепочке Спринтов SCRUM-технологии; 3 - параллельное выполнение двух Спринтов: нового (Спринт Д) и известного (Спринт 2)
6.3. Практические испытания результатов исследования с оценкой их социальных преимуществ перед известными методами
В Центре реконструктивной и восстановительной медицины (Университетской клинике) Одесского национального медицинского университета были проведены испытания системы оптимизации процесса принятия проектных решений при проактивном управлении проектами и программами в медицинской практике.
Система была задействована для управления программой выбора лечебной стратегии и тактики при проведении оперативного и химиотерапевтического лечения методом hyperthermic intraperitoneal chemotherapy (HIPEC). HIPEC - это тип гипертермической терапии, применяемой в сочетании с хирургическим вмешательством в лечении прогрессирующих брюшных раковых заболеваний [12]. В этой процедуре прогретые противораковые лекарственные средства вводят и циркулируют в брюшной полости (животе) в течение короткого периода времени.
Подтверждена возможность эффективного использования новых проектно-ориентированных методов и моделей для успешного проактивного управления процессом медицинского вмешательства ответственного назначения.
В рамках испытаний были проведены 19 операций методом HIPEC, - 10 человек (среди них - 6 женщин) возрастом от 54 до 67 лет были прооперированы с использованием результатов настоящих исследований, т. е. с применением проектного менеджмента в рамках SCRUM-технологии. 9 человек (контрольная группа, среди которой - 4 женщины) возрастом от 48 до 63 лет были прооперированы «обычным» способом.
Выходом системы - показателями качества выполненных операций - были приняты следующие показатели: резектабельность (удалимость) первичной опухоли, улучшение качество жизни (по данным опросника SF-36) в послеоперационном периоде и количество больных, продолжительность жизни которых превысила 1 год после установления диагноза и начала специального лечения.
Испытания продолжались 1 год и 2 месяца. Результаты на протяжении этого времени накапливались и подвергались статистической обработке по методике, изложенной в [20].
Испытания системы показали, что ее использование позволило усовершенствовать оперативные доступы для установки дренажных систем для химио-перфузии в брюшную полость. Разработаны критические параметры температуры (40,5-42 °С) и времени воздействия (1,5-2 часа) перфузионной жидкости на опухолевые клетки и органы брюшной полости.
Сравнение показателей специального операционного лечения методом HIPEC у 19-ти пациентов с диссеминированными распространенными опухолями органов брюшной полости, выполненного с применением SCRUM-технологии управления проектами и у контрольной группы больных по принятой ранее методике показали следующий официально подтвержденный положительный статистический клинический эффект:
за счет усовершенствования оперативного доступа для установки дренажных систем для химиоперфузии в брюшную полость резектабельность (удалимость) первичной опухоли увеличилась до 65 % (в 2,3 раза по сравнению с контрольной группой);
- на 43 % по данным опросника SF-36 улучшилось качество жизни в послеоперационном периоде;
- на 23 % увеличилось количество больных, продолжительность жизни которых превысила 1 год после установления диагноза и начала специального лечения.
7. SWOT-анализ результатов исследований
Strengths. Сильными сторонами результатов исследований является повышение эффективности проактивного (упреждающего возникновение рисковых событий) управления течением хирургического воздействия на человека. Такая эффективность определяется двумя факторами: снижением вероятности рисковых событий и цены (в медицинском и денежном выражениях), затрачиваемой на их компенсацию, если эти события все же произошли.
Weaknesses. Недостаток объекта исследования заключаются в необходимости привлечения в Команду проекта медицинских специалистов, дополнительно владеющих знаниями и умениями в области проектной деятельности, понимающих миссию и цели проектов, умеющими мыслить категориями «структура» и «содержание» SCRUM-технологий управления.
Opportunities. Предложенный подход был практически испытан при использовании хирургической методики hyperthermic intraperitoneal chemotherapy (HIPEC) при оперативном лечении диссеминированных опухолей брюшной полости. Перспектива использования результатов исследования состоит, прежде всего, в расширении области медицинского применения этих результатов на другие хирургические методики лечения других заболеваний.
Threats. Отрицательное действие на объект исследования внутренних и внешних факторов, которые неизбежны при медицинском вмешательстве. Для устранения таких угроз менеджер и Команда проекта должны быть готовы в любой момент перейти на «ручное управление» проектом.
Дополнительные затраты могут быть связаны с приобретением дополнительного аппаратного и программного обеспечения для компьютерной поддержки SCRUM-технологий управления, а также с обучением медицинского персонала действиям в условиях SCRUM-технологий.
У применения SCRUM-технологий управления проектами в хирургической практике нет аналогов. По сравнению же с «обычными» хирургическими операциями удалось увеличить продолжительность и качество жизни прооперированных больных.
8. Выводы
1. Предложена концепция планирования и управления отдельными этапами (Спринтами) проекта управления хирургической операцией, которая состоит в том, что из перечня исполнителей проекта исключается роль Владельца. В медицинской практике Владелец проекта - сам пациент, поэтому эта роль частично передается Менеджеру проекта и частично - новой категории «Родственники пациента».
2. Предложена новая система поддержки принятия решений в проактив-ном управлении структурой и содержанием операций в хирургической меди-
цинской практике на основе SCRUM-технологии. Особенностью системы является то, что она позволяет оценивать вероятность наступления внутренних и внешних существенных рисковых событий и изменять под влиянием этой оценки первоначально запланированную последовательность Спринтов в SCRUM-технологии.
3. Сравнение показателей специального операционного лечения методом HIPEC у 19-ти пациентов с диссеминированными распространенными опухолями органов брюшной полости, выполненного с применением SCRUM-технологии управления проектами и у контрольной группы больных по принятой ранее методике, показали официально подтвержденный положительный статистический клинический эффект.
Литература
1. Schwaber, K. The Scrum Guide [Electronic resource] / K. Schwaber, J. Sutherland. - 2016. -17 p. - Available at: \www/URL: https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf
2. Pichler, R. Agile Product Management with Scrum: Creating Products that Customers Love [Text] / R. Pichler. - Upper Saddle River: Addison-Wesley, 2010. - 133 p.
3. Johnson, H. L. ScrumMaster vs scrum master: What do you think? [Electronic resource] / H. L. Johnson // Agile Learning Labs. - January 13, 2011. - Available at: \www/URL: http://www. agilelearninglabs. com/2011/01/scrummaster-vs-scrum-master
4. Gogunskii, V. D. Upravlenie kompleksnymi riskami proekta soprovozhdeniia sis-tem avariinoi zashchity obiektov otvetstvennogo naznacheniia [Text] / V. D. Gogunskii, T. V. Bibik, I. I. Stanovska // Vestnik Natsional'nogo universiteta korablestroeniia. - 2012. -No. 2. - P. 104-108.
5. Bibik, T. V. Desinhronizatsiia posledstvii avarii na atomnyh elektrostantsiiah [Text] / T. V. Bibik, T. I. Nosenko, D. A. Punch, L. A. Odukalets // Zbirnyk naukovykh prats Instytutu problem modeliuvannia v enerhetytsi im Pukhova NANU. - 2010. - No. 56. - P. 100-105.
6. Brajesh, K. The Product Owner's Role in Technical Matters. Scrum Alliance [Electronic resource] / K. Brajesh // Scrum Alliance. - December26, 2013. - Available at: \www/URL: https://www.scrumalliance.org/communitv/articles/2013/december/prDduct-owner-should-not-interfere-in-techincal-as
7. Liang, Y. The best anesthesia regimen for patients undergoing cytoreductive surgery and hyperthermic intraperitoneal chemotherapy [Text] / Y. Liang, S. Wang // International Journal of Surgery. - 2015. - Vol. 19. - P. 103. doi: 10.1016/j.ijsu.2015.05.022
8. Kolesnykova, K. The project management of the building structure reengineering by the limits in all functional areas [Text] / K. Kolesnykova, D. Monova, A. Toropenko, O. Toropenko, A. Sh. Ali // Technology Audit and Production Reserves. - 2016. - Vol. 5, No. 2 (31). - P. 18-23. doi:10.15587/2312-8372.2016.79982
9. Vladelec producta [Electronic resource] // The Improved Methods. - Available at: \www/URL: http://tim.com.ua/tag/vladelec-producta/
10. Pihler, R Kto takoi vladelets produkta? [Electronic resource] / R Pihler // Upravlenie produktom v Scrum. - Available at: \www/URL: http://rutlib2.com/book/26423/p/3
11. Chernov, S. K. Uchet riskov i neopredelennostei v organizatsionnyh proektah [Text] / S. K. Chernov // Upravlinnia proektamy ta rozvytok vyrobnytstva. - 2006. - No. 1 (17). - P. 41-44.
12. Lotti, M. Laparoscopic HIPEC: A bridge between open and closed-techniques [Text] / M. Lotti, M. Capponi, D. Piazzalunga, E. Poiasina, M. Pisano, R Manfredi, L. Ansaloni // Journal ofMinimal Access Surgery. - 2016. - Vol. 12, No. 1. - P. 86-89. doi: 10.4103/0972-9941.158965
13. Yang, Y. Dual stimulus of hyperthermia and intracellular redox environment triggered release of siRNA for tumor-specific therapy [Text] / Y. Yang, Y. Yang, X. Xie, X. Xu, X. Xia, H. Wang et al. // International Journal of Pharmaceutics. - 2016. - Vol. 506, No. 1-2. -P. 158-173. doi:10.1016/i.iipharm2016.04.035
14. Ramingwong, S. The Paradoxical Relationships of Risks and Benefits in Offshore Outsourcing of Software Projects [Text] / S. Ramingwong, L. Ramingwong // The Open Software Engineering Journal. - 2009. - Vol. 3, No. 1. - P. 35-38. doi: 10.2174/1874107x00903010035
15. Schmidt, R. Identifying Software Project Risks: An International Delphi Study [Text] / R. Schmidt, K. Lyytinen, M. Keil, P. Cule // Journal of Management Information Systems. - 2001. - Vol. 17, No. 4. - P. 5-36. doi: 10.1080/07421222.2001.11045662
16. Bushuyev, S. D. Modern approaches to development of the project management methodology [Text] / S. D. Bushuyev, N. S. Bushuyeva // Project management and development of production. - 2005. - No. 1 (13). - P. 5-19.
17. Gogunskii, V. Bushuyev law - the guarantee of incomplete transformation of serial projects in operating activities [Text] / V. Gogunskii, i. Stanovska, I. Guriev // Eastern-European Journal of Enterprise Technologies. - 2013. - Vol. 4, No. 3 (64). - P. 41-44. -Available at: \www/URL: http://iournals.uran.ua/eeiet/article/view/16279/1379
18. Stanovska, I. I. Prevention and management of risk latency [Electronic resource] / I. I. Stanovska, I. M. Shchedrov, K. I. Berezovska // NUS Journal. Electronic Editon. - 2014. -No. 3. - Available at: \www/URL: http://evn.nuos.edu.ua/article/view/44133/40375
19. Stanovskyi, O. Dynamic models in the method of project management [Text] / O. Stanovskyi, K. Kolesnykova, O. Liebedieva, I. Heblov // Eastern-European Journal of Enterprise Technologies. - 2015. - Vol. 6, No. 3 (78). - P. 46-52. doi: 10.15587/1729-4061.2015.55665
20. Spriestersbach, A. Descriptive Statistics: The Specification of Statistical Measures and Their Presentation in Tables and Graphs - Part 7 of a Series on Evaluation of Scientific Publications [Text] / A. Spriestersbach, B. Rohrig, J.-B. du Prel, A. Gerhold-Ay, M. Blettner // Deutsches Aerrzteblatt Online. - 2009. - Vol. 106, No. 36. - P. 578-583. doi: 10.3238/arztebl.2009.0578
