OMG Essence и OKR – многофокусное ведение проектов и бизнеса в целом

В прошлой статье «Public web — следуем за потребителем» мы говорили о практиках и технологиях public web следования за потребителем при высоком темпе изменений. А в этой, 25 статье серии «Менеджмент цифрового мира» (оглавление) мы поговорим о тех изменениях, которые последовали приходом в корпоративную разработку по мере реализации тренда Web-Scale IT for Enterprise, и прежде всего о DevOps. А также о подходах к ведению многофокусных проектов – OMG Essence и OKR.

Сегмент public web по природе своей устроен таким образом, что разработка софта напрямую решает бизнес-задачи, держа в фокусе привлечение потребителей и удовлетворение их потребностей. Правда, даже там это осзнание пришло не сразу, инженерам свойственна иллюзия, что хорошая идея обязательно будет оценена, «продаст сама себя». Особенно лучшим, я давал ссылку на пост Джеймса Уиттакера (2012), в котором фактически, описана история того, как с этой иллюзией справлялся Google.

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

Естественно, такие изменения не происходят одномоментно во всей отрасли. И, более того, они далеко не всегда осознаются в сообществе, потому что практика работы с удовлетворенностью стейкхолдеров была известна задолго до описываемых изменений, и ее реально применяли. Разница возникает при появлении проблем в проекте. Классический подход предлагает руководителю IT-проекта объяснить стейкхолдерам их объективный характер и смягчить негатив, при этом сам проект полагает в целом успешным. Новый подход говорит о том, что если проект не решил проблем бизнеса или не дал ему новые возможности, то об успехе говорить бессмысленно. Это ключевое различие отражено на схеме и осенью 2017 я делал об этом изменении доклад на AnalystDays «Удовлетворенность стейкхолдеров – два разных смысла», поняв, что смысловая разница скрыта и не осознается.

Реализация такого изменения естественным образом требует, чтобы команда разработки понимала, какие задачи бизнес хочет решить с помощью софта. И, более того, понимала, каким образом бизнес предполагает это сделать – потому что достаточно часто проблема оказывается именно здесь, функционал на самом деле не пригоден для предполагаемого использования. В ходе совместной работы стейкхолдеров и IT над решением бизнес-проблем происходит сращивание проекта изменений бизнеса и проекта IT-разработки в единый проект, в то время как ранее они мыслились как отдельные проекты. И как развитие этого – превращение IT из обеспечивающей функции в полноценного партнера бизнеса.

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

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

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

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

Отметим, что в современном мире не только IT должно сменить сервисную позицию по отношению к бизнесу на партнерскую. То же можно сказать о пиаре и маркетинге он должен работать не на показатели проведенных мероприятий и акций, а на достижение результатов для бизнеса. А еще то же касается HR – надо не просто закрывать позиции, а совместно с командами обеспечивать эффективную работу нанятых специалистов, и не просто обучать каким-то softskill, а применять их для решения бизнес-задач. Кстати, на РИТ++ был хороший доклад Ольги Давыдовой и Артема Каличкина о поиске HR своего места в современном IT (видео в общем доступе пока нет, но будет).

Название следующего серьезного изменения ведения проектов, которое принесли технологии public web в корпоративную разработку, широко известно – это DevOps. Думаю, концептуальное понимание есть у гораздо меньшего количества народа. Интересно, то DevOps возник не в public web. Там большинство проектов, особенно крупных, развиваются в более продвинутой парадигме NoOps – полного отсутствия эксплуатации как отдельно выделенной стадии жизненного цикла, на которой продукт меняется относительно слабо. Продукты public web интенсивно развиваются и изменяются, а их стабилизация означает, что продукт просто умер.

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

Этот мост между разработкой и эксплуатацией и называется DevOps, и он включает в себя ценности и культуру сотрудничества, а не только процессы. Хороший доклад об этом делал Иван Евтухович на SQAdays-20 (мой конспект). Отметим, что это доклад для IT-шников и на IT-конференции, и в нем множество непонятных широкой публике слов. Однако, во-первых, в нем есть хорошая концептуальная часть.

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

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

Если же отвлечься от конкретики IT, то можно увидеть, что примерно те же изменения, связанные с высоким темпом развития продуктов сейчас характерны и для других отраслей. Как лет 10-15 назад банк осваивал, например, ипотечное кредитование или автокредитование или потребительские кредиты? Это был проект построения бизнес-подразделения, который шел пару лет с развитием продукта и конкретных условий, и это казалось очень быстро. А потом продукт и подразделение стабилизировалось и несколько лет продавало созданный продукт со слабыми вариациями – до следующего изменения рынка. И это делали люди практически по скриптам, созданным при разработке продукта, с редким обновлением и переобучением.

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

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

Все это требует новых подходов к ведению IT-разработки, и такой подход был создан большой инициативной группой под руководством Ивара Якобсона и получил несколько претензионное название «The Essence of Software Engineering». Впрочем, они действительно выделяли суть, а не изобретали оригинальный подход. Они провели анализ множества способов ведения реальных проектов, и выяснили, что все из них можно представить как ту или иную комбинацию примерно 250 практик. А дальше они придумали способ, которым практики и их комбинации можно формально описывать, и сделали эти описания.

Результат получил статус стандарта Object Management Group (OMG), которая в свое время была создана для того, чтобы объектно-ориентированный подход не был уделом методологов разных компаний, которые тянули его каждый в свою сторону, а в кооперации развивался IT-сообществом. Так что претензионность названия оказывается оправданной, а краткое название «OMG Essence» ее еще больше смягчает . Стандарт доступен на сайте OMG, и в нем не только описан сам формализм, но и описаны конкретные методы, такие как Scrum и Waterfall, а также показаны возможности расширения методов, например, как меняется описания Scrum, если использовать User Story вместо абстрактных Product Backlog Item, или что изменяется при добавлении в процесс практик Business Analysis и работы с нуждами стейкхолдеров.

Подробное описание с примерами есть в книге Ивара «The Essence of Software Engineering». Кроме того, можно послушать доклад Ивара на SECR-2017 «Kill All Methods – Free the Practices»

А у него на сайте есть Practice library (доступна после бесплатной регистрации), откуда можно получить описание SAFe, разных вариантов Agile-методов, вариант итеративного RUP, переработку метода Use Case так, чтобы он стал совместим с частичной реализацией use case, необходимой для выделения MVP (Use Case 2.0) и многое другое. И эта библиотека описаний позволяет не конструировать с нуля, а активно заимствовать и технологично собирать собственный метод для проекта из разных практик.

В чем же состоит основная идея? Она заключена в концепции Альф деятельности – синтетических объектов, состояние которых отражают ее продвижение к целям и здоровье. Выявлено, что требуется отслеживать минимум семь альф. Можно больше, но эти семь – необходимы.

• Альфы потребителя: Opportunity – возможности для бизнеса и Stakeholder
• Альфы системы: Requirements и Software system
• Альфы деятельности, Endeavor (у слова нет хорошего русского перевода, Левенчук предложил «предприНятие»): Work, Team и Way of working (технологии).
  

На схеме представлены альфы и их взаимосвязи в нотации OMG Essence. Активное использование схем, обеспечивающее легкий вход и понимание метода. Оно основано на опыте IT и, в частности UML, в которое Ивар Якобсон в свое время внес большой вклад.

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

Жизненный цикл проекта в целом определяется интегрально, по всем альфам. Переход альфы на следующую стадию определяется с помощью чек-листа, и в стандарте приведены чек-листы для альф, с которых можно начать. А дальше у вас – большое поле кастомизации, настройки метода проекта на ваши индивидуальные особенности. Если вы полагаете, что какие-то аспекты для ваших проектов особенно важны и недостаточно отражены в чек-листе – вы дописываете новые пункты. Можно также переносить их между фазами проекта, если у вас другая динамика развития проекта. Можно добавлять свои фазы, если это необходимо.

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

Понятно, что изменяются именно эти физические объекты – компоненты системы проектируются, разрабатываются, тестируются, передаются в эксплуатацию и дорабатываются, стейкхолдеры идентифицируются и вовлекаются в сотрудничество, сотрудники включаются в команды, которые проходят по пути от формирования до слаженной работы. Состояния физических объектов тоже отслеживаются, однако при необходимости можно отслеживать состояние отдельных интегральных объектов. Например, компетенции команды разработки, если идет речь о применении новых технологий, или выделить из opportunity отдельную альфу стратегирования, чтобы продвижение по стратегии не потерялось на фоне текущей деятельности.

Отметим, что такой подход OMG Essence к адаптации: возьми простое и далее наращивай сложность по необходимости – принципиально отличается от подходов RUP или PMBOK, которые предоставляют описание для сложного случая, предлагая вычеркивать лишнее, но не объясняя, как при этом не разрушить целостность. Он реально снижает порог входа для инструмента. И его можно применять не только комплексно, но и сфокусированно на проблемных альфах. Например, для формирования команд под пресейлы – задачи, которая актуальна для многих IT компаний. Об этом опыте в компании CUSTIS рассказывал Ольга Цыганова на конференции «Прикладное системное мышление»: презентация, видео.

Легкий вход – это как раз тот урок, который извлек Ивар Якобсон из опыта RUP, это было одним из фокусов группы авторов. В этом смысле очень интересно посмотреть на опыт освоения OMG Essence Анатолием Левенчуком, который я наблюдаю с его обзора в 2012 году (мой пост). Анатолий любит смотреть все новое, и OMG Essence его заинтересовал, однако первые посты критиковали его за ограниченность средств. Однако, введя его в свой курс в МФТИ вместо ранее используемых там стандартов, он оценил преимущества низкого порога входа: подход понимали студенты и аспиранты. А позднее оказалось, что менеджеры тоже его хорошо понимают. Так OMG Essence был адаптирован для системной инженерии и вошел как важная составляющая в курс системноинженерного мышления, который превратился в нынешний курс системного мышления.

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

И в заключении отмечу, что в России OMG Essence известен слабо, а в мире он не просто известен – более сотни университетов разных стран сделали его основой преподавания курсов, на которых обучают вести проекты, об этом говорил Ивар, когда приезжал в 2017, так что сейчас, думаю, их уже больше. И, думаю, это как раз связано с низким порогом входа.

Упоминание метода Objectives and Key Results (OKR) в списке новых инструментов может вызвать недоумение. Ведь сам метод Andy Grove придумал давно, в 1970. Дело в том, что именно этот метод в 2000-х взял Google для работы с целями внутри компании, при этом адаптировал практику применения для IT и согласовал с другими практиками ведения разработки. И потому он стал популярен в IT и хорошо совместим с Agile-методами для согласования движения разных самоуправляющихся команд к общим целям компании.

Как следует из названия, метод состоит из двух частей: Objectives, которая задает цели движения, и Key Results, показывающая, как именно мы будем определять, что действительно продвинулись по направлению к цели, а не пошли куда-то совсем в другую сторону.

Метод OKR значительно менее распространен и известен, чем Management By Objectives (MBO), что не удивительно – MBO был придуман Питером Друкером еще в 1954 и вошел в учебники по менеджменту. Поэтому у тех, кто изучал менеджмент, со словами «управление по целям» связан именно этот метод. И важно акцентировать внимание на различиях.

Цель в OKR принципиально амбициозна и не достижима. Кроме того, она ставится в той области, где для продвижения надо экспериментировать, ставить и проверять гипотезы, а не выполнять задачи. И поэтому за ее достижение или не достижение и даже за продвижение к ней платить нельзя, как нельзя ученому исследователю платить только за успешные эксперименты. Ключевые результаты при этом – лишь договоренность о том, какой результат эксперимента мы считаем успешным.

В MBO же цели, по сути являются частью планирования, и потому способ движения к цели тоже в целом понятен, и ее достижимость – вопрос усердия и энергии в работе. И естественно платить за ее достижение.

Понятно, что на практике работают композитные варианты, но в любом случае, выполнение цели OKR на 50% считается хорошим результатов, а выше – выдающимся, и обычно сопровождается премиями или другим вознаграждением – в отличии от MBO, который декларирует обязательное достижения цели. Но, повторю, цели OKR – не просто удвоенные планы, потому что простое удвоение делает их не реалистичными и отнимает энергию, а не дает ее.

В соответствии с принципами самоорганизации, цели в OKR принимает команда – руководство компании принимает цели для компании в целом, а далее команда определяет, каким образом она внесет свой вклад в достижение общих целей, согласовывая это, естественно, с руководством компании. Выбор способов достижения целиком в ответственности команды – она сама планирует и проводит эксперименты ,которые должны привести к успеху.

О применении OKR я слушал хороший доклад на AbileBusiness-2018: Ирина Сукманюк. «Цели и ключевые результаты: факторы успеха системы OKR на заводах» (видео), в моем посте по этому докладу мы как раз обсуждали отличия OKR, MBO и KPI. О применении OKR говорят многие компании в IT и за пределами. Например, в уже упоминавшемся в описании кейсов Agile докладе Дмитрия Кондрацкова «Банк Агророс. 550 дней Agile в операционном управлении!» как раз говорили о синхронизации работы команд с помощью OKR.

OKR, подобно Agile требует поддержки на уровне культуры – стремление к цели, культура постоянных экспериментов, признание права на ошибку и неудачу. Без этого компания не может быстро расти. О культуре компании и работе с ней был хороший доклад на SaintTeamLeadConf-2019 Артем Сусеков из Miro «Культура как основа для масштабирования команды х2 каждый год» (публикация видео ожидается, пока есть мой конспект). Доклад, на мой взгляд, дает хорошее представление о работе с культурой в современных IT-компаниях.

На этом я завершаю статью. Следующая статья, как я уже писал, будет про новый социальный контракт сотрудника: работа на цели компании в обмен на условия для счастья на работе. Отмечу, что компании идут на это вовсе не из желания облагодетельствовать сотрудников, просто счастливые люди работают гораздо эффективнее, и это измеримо, а дефицитный рынок труда дает таким компаниям существенное конкурентное преимущество. По мере роста умственного труда это ждет все отрасли, так что читайте!