О стандарте OMG Essence я узнала на Физтехе на курсе по системной инженерии кафедры «Роснано». Тогда в рамках учебного задания я применила стандарт к своему рабочему проекту. Оказалось, что благодаря OMG Essence можно всего за пару недель вместить в голову реальный проект, который рассчитан на 7–10 лет разработки и внедрения.
С тех пор я использую стандарт уже больше 10 лет. Я поработала с ним на разных проектах и в разных ролях: системный аналитик, инженер, руководитель проектов, менеджер по развитию бизнеса.
В своей практике я не сталкивалась с другими стандартами, которые бы давали такую цельную картину проекта минимальными средствами. OMG Essence помогает любому участнику проекта разложить по полочкам требования к системе, ход разработки, удовлетворенность стейкхолдеров, состояние команды и другие ключевые показатели проекта.
История создания
В 2010-х в области разработки ПО назрело несколько глобальных проблем:
из-за большого количество методов и технологий создания ИТ-систем даже опытному разработчику часто приходилось переучиваться при переходе в новый проект;
разные коллективы разработчиков совершали однотипные ошибки. Например, уделяли недостаточно внимания к выработке требований совместно с заказчиком ИТ-системы.
Всё это приводило к тому, что сроки разработки увеличивались, а результат не соответствовал ожиданиям заказчика и запросам бизнеса.
Необходим был общий способ создания ИТ-систем с хорошей теоретической базой, который позволил бы существенно повысить качество результата. Требовалось также, чтобы способ можно было применить к любому ИТ-проекту независимо от отрасли заказчика, численности и уровня знаний команды разработки.
Чтобы решить эту проблему, Ивар Якобсон, Бертран Майер и Ричард Соули занялись разработкой документа Essence Kernel and Language for Software Engineering Methods (или просто Essence). А в 2014 году Object Management Group (OMG) утвердила его как один из своих стандартов. Появление OMG Essence стало важнейшим событием в мире программной инженерии. Стандарт заложил основы для организации промышленной ИТ-разработки и дал всем специалистам в этой области единый универсальный подход.
В России OMG Essence и всем, что касается системной и программной инженерии, занимается русское отделение SEMAT. Они устраивают семинары, конференции организуют учебные курсы в МТФИ, МЭСИ, МИЭМ, ВШЭ и других вузах. Но несмотря на это, в России о стандарте пока мало кто знает.
Преимущества стандарта
Позволяет проверить соответствие реальным потребностям бизнеса
OMG Essence помогает проверить, соответствует ли твоя работа реальным потребностям заказчика. В этом заключается его главное отличие от других стандартов, где используется управление проектами по вехам или контрольным точкам, таких как PMBOK. Ты можешь отслеживать как формальную сторону реализации проекта — завершена ли задача, проведен ли багфикс, сдали ли работы заказчику, так и содержательную — что конкретно делается, как это влияет на другие задачи в рамках проекта, соответствуют ли результаты на каждом этапе ожиданиям стейкхолдеров. Именно содержательную часть каждой задачи обычно сложно контролировать без применения стандарта.
Позволяет охватить проект целиком
OMG Essence покрывает все стороны разработки ИТ-проекта. Другие стандарты, как правило, — только одну или несколько.
Может быть использован любой командой
Стандартом могут пользоваться все, кто проектирует ИТ-системы, и при этом неважно, для какой отрасли. Численность команды также не имеет значения — это может быть целый департамент или один человек.
OMG Essence будет полезен специалистам в любой проектной роли: от руководителя до архитектора. Их квалификация или уровень знаний не имеют значения.
Совместим с любыми другими стандартами, методами и практиками
Стандарт гибкий и может дополняться любыми методами и практиками. А еще он никак не препятствует применению любых других стандартов.
Не только выявляет проблемы, но и предлагает их решение
Стандарт предлагает набор готовых рекомендаций для реакции на любые отклонения от желаемого состояния здоровья проекта в соответствии с этапом жизненного цикла. Вы сможете не только оценить положение дел на проекте, но и понять, что с этим делать дальше.
Удобен в применении
Стандарт адаптирован для практического применения. По нему есть все необходимые материалы — чек-листы, карточки, таблицы, — которые упрощают работу с ним.
Для первых итераций это можно использовать. В процессе работы автоматически захочется дополнить их своей конкретикой. И да, если так происходит, вы на верном пути!
Принцип применения OMG Essence улавливается интуитивно: понятия фиксируются с помощью значков, что экономит время и позволяет погрузиться в контекст даже неспециалисту.
Суть стандарта
Основная идея OMG Essence состоит в том, чтобы отслеживать изменение состояний ключевых элементов проекта. Эти элементы называются альфами (ALPHA — Abstract-Level Progress Health Attribute — абстрактное понятие, описывающее один из атрибутов «здоровья» проекта). Стандарт предполагает, что обязательно нужно отслеживать семь альф:
Альфы клиента: opportunity — возможности для бизнеса и stakeholder — стейкхолдеры;
Альфы инженерного решения: requirements — требования (описания системы) и software system — сама ИТ-система;
Альфы усилий: work — работа, team — команда и way of working — технологии.
В ходе работы над проектом альфы изменяют свое состояние. Эти изменения показывают, как развивается проект. Но важно помнить: движение по состояниям альф само по себе не означает, что вы идете к нужной цели и все части проекта разрабатываются согласованно.
Проверить, насколько точно на каждом этапе достигаются цели, помогают рекомендованные (правильные) состояния альф и контрольные списки состояний.
Итак, мы выяснили откуда и зачем появился стандарт и какие задачи можно решить с его помощью. В этом месте можно почитать список литературы для тех, кому интересно узнать все подробности (рекомендую читать в предложенном порядке).
Литература по стандарту
Страница стандарта на сайте консорциума OMG https://www.omg.org/spec/Essence/1.2/About-Essence/ и текст стандарта https://www.omg.org/spec/Essence/1.2/PDF
Декабрь 2012, “The Essence of Software Engineering: The SEMAT Kernel. A thinking framework in the form of an actionable kernel”
Май 2015, статья на Хабре, «SEMAT? Приятно познакомиться»
Общий список литературы
На русском языке:
Март 2020, доклад на конференции ШСМ, «Обучение сотрудников практикам OMG Essence», видео доклада
Январь 2020, статья на vc.ru «OMG Essence и OKR — многофокусное ведение проектов и бизнеса в целом»
Апрель 2018, доклад на конференции ШСМ «Практика контрольных вопросов OMG Essence в ИТ-проекте», презентация
Май 2015, статья на Хабре «SEMAT? Приятно познакомиться»
Ноябрь 2014, статья «SEMAT — Software Engineering Method and Theory. О чем, зачем и кому это нужно?» (стр. 3)
Май 2015, доклад «Essence для управления технологиями» на 4-ой научно-практической конференции «Актуальные проблемы системной и программной инженерии» (АПСПИ-2015)
Февраль 2013, доклад А. Байда «Стандарт OMG Essence и работа инициативы SEMAT» в русском отделении INCOSE
Июнь 2013, Летний аналитический фестиваль, доклад «Стандарт OMG Essence — в чем польза для аналитика?»
Декабрь 2012, текст в ЖЖ, «Основа — сущности и язык для методов программной инженерии (OMG Essence)»
На английской языке:
Страница стандарта на сайте консорциума OMG https://www.omg.org/spec/Essence/1.2/About-Essence/
Спецификация стандарта от 2018 года, версия 1.2 https://www.omg.org/spec/Essence/1.2/PDF
Декабрь 2012, “The Essence of Software Engineering: The SEMAT Kernel. A thinking framework in the form of an actionable kernel”
Ноябрь 2013, статья “Agile and SEMAT— Perfect Partners”
Ноябрь 2014, статья “A New Software Engineering”
Февраль 2014, статья “Major-league SEMAT — Why Should an Executive Care?”
Алгоритм применения
А теперь — как обещала — переходим от теории к практике. Этот гайд про то, с чего начать, если решили применить стандарт OMG Essence к своему ИТ-проекту. Здесь не будет очередного набора концептов для общего развития. Взамен этого я постараюсь дать знания, которые оптимизируют вашу работу.
WARNING! Гид подойдет тем, у кого есть реальный ИТ-проект и кто способен быстро осваивать материал, применяя его в работе. И категорически не подойдет тем, кто сначала все основательно читает! Что делать в таком случае, обсудим в комментариях, пишите :)
1 раунд
Назовите свою роль на проекте. Ролей может быть несколько, чаще всего это так. Например, я работаю бизнес-аналитиком на проекте, или архитектором, или инженером по требованиям. Должен получиться столбик из названий ролей.
Название должности ≠ роль! «Начальник отдела разработки» — это должность, на которой у человека может быть много ролей. Например, такие: лидер, операционный менеджер, логист задач (операционный менеджер), архитектор.
ФИО человека ≠ роль! Кажется, это совсем очевидно. Но бывает смешно, когда обнаруживаю «Андрей Андреевич», читая чей-то список стейкхолдеров (внешних проектных ролей).
В зависимости от момента времени вы можете играть разные роли. Вот вы сидите и пишите код: вы — писатель кода. А вот распределяете задачи по своим коллегам: вы — операционный менеджер.
Откройте методичку (стр. 6) и прочитайте, что такое область интересов и какие они бывают:
Отнесите каждую свою роль к какой-то из областей интересов: клиентская, инженерного решения, область усилий. Например, если вы программист, это может быть область инженерного решения, для операционного менеджера — область усилия. Или если я продаю ИТ-продукт, то моя область интересов — клиентская.
На что обращать внимание:
Одна ваша роль может относиться к одной (чаще!) или двум областям интересов. Если появляются две или три области, то это сигнал проверить, насколько тщательно вы отделили роль от еще какой-либо.
Для нескольких ролей, которые могут играть люди на ИТ-проекте, мы с фанатом стандарта OMG Essence составили таблицу соотношения ролей, областей интересов и альф:
Если на пересечении названия роли и альфы закрашена ячейка, то эта роль двигает альфу по своим состояниям. Что создает артефакты, по которым можно отслеживать состояние альфы.
Приведу пример из своего опыта. На одном из проектов я была предпринимателем, архитектором по требованиям и бизнес-аналитиком. Мне нужно было построить оргпроект, который бы в свою очередь построил инженерный проект, а тот — ИТ-систему:
В роли менеджера по развитию бизнеса я искала возможность реализации проекта, заинтересованных в системе людей. Смотрела, кто для проекта нужен, есть ли такие эксперты у нас в компании и на рынке труда в целом. Прикидывала, какие технологии могут потребоваться для реализации проекта и существуют ли специалисты с такими компетенциями. А ещё нужно было обеспечить требования госрегуляторов к разрабатываемой системе.
Как архитектору мне нужно было понять, будет разрабатываться проект с нуля или уже есть продукты, используя которые можно представить нужный заказчику функционал.
Как бизнес-аналитик я собрала требования по функциональности системы с заказчика. ИТ-система должна была реализовывать такие функции: автоматизировать ведение медицинской карты и записи на приёмы ко врачам, а также ведение результатов лабораторных анализов.
То есть я работала с областью Customer — клиентской или областью возможностей, и с инженерной (Solution), поскольку в ходе проработки предложения для клиента необходимо было принять некоторые архитектурные решения, например, сделать разработку с нуля или использовать несколько готовых продуктов, которые объединяются в единое решение.
Возьмите для примера одну свою роль и одну область интересов, к которой она относится. Сравните с тем, какие альфы относятся к этой области интересов в самом стандарте (стр. 16, раздел 8.1.4).
Там же (стр. 17, раздел 8.2) прочитайте определения каждой альфы из вашей области интересов.
Дальше выберите одну любую альфу из вашей области интересов. Например, я — операционный менеджер, выбираю альфу «Работа».
Теперь выделяете экземпляр альфы «Работа». Например, «надо поставить Пете задачу написать use case для Вани» или «моя задача сейчас — сделать предложение бэклога на следующий спринт».
Соответственно, в моём примере выше, где я была менеджером по развитию бизнеса, я привела пример для альфы «Возможность».
Открываете в стандарте (стр. 19, раздел 8.2) таблицу с состояниями этой альфы и ставите галочки там, где состояние пройдено. Где оно не пройдено, не ставите.
Для удобства рекомендую воспользоваться чек-листами, которые мы используем на воркшопах по OMG Essence у нас в компании, вот ссылка.
Эта форма представления подойдет для тех, кому сложно читать оригинал стандарта на английском, кто хочет удобную форму заполнения чек-листов, кому нужна основа своих будущих чек-листов, в которой можно будет чиркать и писать свои перечни (об этом дальше).
Сейчас в эксельке заполнена вкладка «Возможность» для пресейл-проекта, по которому мы прорабатывали возможность реализации ИТ-системы для заказчика.
Как видно по таблице, мы проработали стадию «Концепции». Проставленные галочки на вкладке «Возможности» показывают, что мы ещё не залезли в состояние «Жизнеспособна» и должны проанализировать, насколько такая система реализуема с нашими текущими ресурсами (тоже «Возможности»).
В этом проекте не требовалось детально прорабатывать все риски и как с ними обходиться, можно было не собирать команду поимённо. Целью было выяснить примерные сроки сборки ИТ-системы и понять, насколько они вписываются в общий срок реализации проекта.
В целом далее нужно переходить на следующий этап и прорабатывать его. Такой переход не обязательно означает, что дальше над проектом работает другой человек. Кто его будет выполнять, зависит от ролей — это можете быть опять вы или вас заменит коллега.
В итоге у вас получится состояние конкретной альфы, отображенное в гугл-таблице.
Поздравляю, вы поняли машинерию альф, их состояний и чек-листов! Теперь вы можете выделить альфы, экземпляры ваших альф и рассмотреть, в каком состоянии они находятся. А еще получить артефакт, в котором это будет зафиксировано.
2 раунд
Между раундами 1 и 2 может пройти от недели и более. Это нормально.
На моём проекте переход занял около двух месяцев. За это время я успела плотно поработать с заказчиком, ознакомиться с законодательными и нормативными документами, проконсультироваться с архитектором, который помогал проверять техническую реализуемость функциональных требований заказчика.
Теперь немного сложнее. Берете любую альфу из тех, что лежат в вашей области интересов, и определяете ее состояние по чек-листам из п. 8.
На что обращать внимание:
Когда вы будете это делать, вам захочется переписать чек-листы под себя, — вы на верном пути! Вы поняли, что стандарт абстрактный, а в жизни все иначе. Изменяйте чек-листы, пишите их под свои альфы!
В работе со стандартом не всё сразу будет понятным. У меня есть документ с вопросами, которые мне задают люди, когда начинают перемалывать свои ИТ-проекты через OMG Essence. В документе я даю подробные ответы, он постоянно дополняется. Последнюю версию можно почитать здесь.
Есть и 3 раунд. Он отразит состояние вашего проекта, основываясь на предыдущих раундах.
Для тех, кто дотянет до этого места — приз! Это алгоритм, который покажет, как определить минимальный и достаточный набор действий, чтобы перевести свой ИТ-проект в нужное состояние, имея состояния его альф.
Алгоритм здесь.
Пройдя с 1 по 3 раунды, вы получите:
Состояния альф своего ИТ-проекта;
Чек-листы для собственных альф;
Список необходимых и достаточных действий, которые нужно совершить, чтобы перевести свой ИТ-проект в нужное состояние.
На этом всё! Благодаря OMG Essence можно за две недели освоиться с реальным проектом, который рассчитан на десятилетие разработки и внедрения, — стандарт покажет цельную картину. Применяйте его, пользуйтесь полезными ссылками, и вы увидите, что OMG Essence — это просто.
Делитесь в комментариях своим опытом!
