Текст книги "Менеджмент цифрового мира"

Опыт показывает, что никакое изучение пользователя не дает гарантии, что очередной продукт ему понравится и будет иметь успех, что новые изменения привлекут посетителей на сайт, а не оттолкнуть их. И поэтому изучение user experience дополняется постоянной проверкой гипотез, A/B тестированием на реальных пользователях. Этот процесс поставлен на поток, в таких интернет-компаниях, как Яндекс в тестировании параллельно находятся десятки, если не сотни изменений, каждое из которых оценивается на отдельной испытательной и контрольной группах, при этом в той или иной мере в испытания вовлечены более половины пользователей.

По сути, A/B тестирование представляет собой проверку: а принесла ли новая функциональность действительную ценность пользователю. Естественно, что постоянная проверка гипотез и доработка функционала порождает практики постоянного мониторинга состояния продукта в реальном времени. Мониторинг отражает не только техническую работа софта, но и его бизнес-показатели для компании, а так же получение ценности пользователями и их удовлетворенность.

A/B тестирование – проверка: принесла ли новая функциональность ценность пользователю.

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

По сути, можно говорить о том, что развитие интернет-проектов представляет собой непрерывную череду стартапов, каждый из которых должен завершиться успехом или провалом в очень короткий срок, как правило 2—3 месяца. В некоторых компаниях это является правилом: если новая инициатива не приносит результата за этот срок, то она безусловно закрывается.

Однако, все эти стартапы разворачиваются не «в чистом поле», а вокруг одного и того же продукта, с общей кодовой базой. В некоторых случаях это требует существенной реорганизации команд, и IT умеет это делать в условиях эксплуатации продукта. Фронтирным примером тут может служить опыт ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам.

При таком режиме работы совершенно нерелевантным становится традиционный процесс годовых бюджетов, и IT с этим тоже умеет работать. Впрочем, в большом корпоративе эта проблема тоже решается, и тут есть интересный подход Beyond budgeting. Я о нем слушал доклад Bjarte Bogsnes, Vice President норвежской компании Statoil (крупнейшая нефтегазовая компания Европы) «Beyond Budgeting – an agile management model for new business and people realities – the Statoil implementation journey» (видео, мой конспект) на IT Spring-2017. У подхода есть свой сайт http://bbrt.org, можно изучать.

А еще интернет-проекты живут совершенно в другом темпе, чем традиционные отрасли. Там характерный темп изменений измеряется часами, максимум – днями. В то время как в других отраслях темп изменений измеряется неделями и месяцами, а то и годами, многие компании продолжают жить до сих пор. Двухнедельные спринты Scrum и ежедневный пульс daily scrum, который показывали доска и burndown 15—20 лет назад были прорывом. Сейчас темп еще увеличился, и сроки реализации от идеи до выкатки на промышленные сервера часто исчисляются днями, если не часами, и даже ежедневные релизы становятся слишком редкие, идет переход на непрерывную отгрузку нового функционала, continuous delivery, до сотен в сутки. И такой темп принципиально изменяет организацию проекта и темп жизни в public web – часы, максимум дни, а не недели и месяцы

Отметим, что в отраслях реального производства темп тоже увеличивается. Примером может служить fasion-индустрия. Традиционно крупные бренды жили в медленном ритме сезонных коллекций, выпуская две коллекции в год, при этом цикл жизни коллекции от начала разработки до окончания сезона продаж составлял около двух лет. Сейчас многие компании разрабатывают коллекции, которые продаются всего 2—4 недели, при этом цикл жизни коллекции тоже сократился до 3—6 месяцев при том, что значительную часть занимает логистика из Китая или Юго-Восточной Азии. Кстати, чтобы сократить цикл, некоторые компании осваивают производство в России, а часть итальянских брендов начала шить в Польше или Львове.

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

И эти механизмы будут только совершенствоваться и захватывать все больше сегментов бизнеса, и они доступны всем, а не только большим компаниям. Еще в 2015 я на SECR-2015 слушал доклад Сергея Дмитриева, где он демонстрировал как буквально с помощью 10 строк кода с помощью сервисов IBM банк может по текстам переписки с клиентом получить его психологический портрет, который дальше использовать для персонализации предложения по продуктам (видео, мой конспект). А сейчас ряд платформ уже выдают психологический профиль пользователя в те миллисекунды при показе страницы, когда на невидимой бирже идет торговля за то, какая реклама этому пользователю будет показана – и в зависимости от этого рекламодатели могут предлагать разную цену показа.

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

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

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

Мы говорили о практиках и технологиях public web следования за потребителем при высоком темпе изменений. А теперь мы поговорим о тех изменениях, которые последовали приходом в корпоративную разработку по мере реализации тренда 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 становится из обеспечивающей системы полноценным партнером бизнеса. А по мере развития цифрового мира превратится в ведущего партнера

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

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

Однако, в принципе в юридическом поле проблема такого контракта уже решена – речь идет о неоклассическом реляционном контракте.88
  По-русски смотри Э.Г.Фуруботн, Р. Рихтер «Институты и экономическая теория», раздел 4.4.3 «Теория отношенческих контрактов» (ссылка ведет на archive.org с текстом книги, в других местах опубликован лишь pdf).


[Закрыть] Контракт предназначен для условий, когда обе стороны признают высокую неопределенность и изменчивость условий деятельности, которая не позволяет заложить контракт условия деятельности, и вместо этого закладывают общие принципы и процедуру изменения текущих договоренностей.

Отметим, что в современном мире не только 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 (http://omg.org), которая в свое время была создана для того, чтобы объектно-ориентированный подход не был уделом методологов разных компаний, которые тянули его каждый в свою сторону, а в кооперации развивался 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 https://practicelibrary.ivarjacobson.com/ (доступна после бесплатной регистрации), откуда можно получить описание 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 год. Курс был доступен на курсере бесплатно, а за небольшую денежку вам проверят задания. Есть новый учебник курса, существенно обновленный Анатолием в мае-июне 2019 года, и в этом посте ссылки на публикации, включая чаты, в которых он бесплатно выложен, а также отличия новой версии. Основное отличие не в появлении нового содержания, а в существенном улучшении терминологии и изложения на основе опыта обучения. Так что если читать – то новый учебник. А если вы хотите пройти курс, то можно сделать это на курсере или подождать, когда появится курс в новом варианте.99
  Это – текст начала 2020 года. С тех пор курс несколько раз переписывали, по сути он разделился на несколько различных курсов. Текущее состояние смотри в программе школы системного менеджмента Анатолия Левенчука, как и раньше в онлайн-варианте курсы доступны бесплатно, а за задания надо платить.


[Закрыть]

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