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

Agile и регулярный менеджмент

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

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

А теперь теперь – немного статистики про успешность Agile-методов. Тем более, что в комментариях к одной из моих статей про Scrum, как это часто бывает, появились люди, утверждающие что никаких данных и никакой статистики, подтверждающей эффективность Agile-методов даже в IT, нет и все это – чистая пропаганда. Я знаю, что статистика есть, я ее слышал в ряде докладов, в том числе – в докладе Сазерленда на SECR-2011, ссылку на который привел. Но такие люди обычно не хотят истины, они хотят лишь увериться в правильности своего мнения. Поэтому подобные ссылки быстро объявляют предвзятым мнением, а не разбираются. И, поскольку у всякой такой дискуссии есть читатели, то я сделал еще пару шагов, результаты которых тут публикую. Я довольно быстро вышел на статью Michael Sweeney Agile vs Waterfall: Which Method is More Successful? со статистикой и ссылками и на несколько отчетов55
  Прямая ссылка не работает, смотрим через archive.org


[Закрыть]. 2013 IT Project Success Rates Survey Results, 2018 IT Project Success Rates Survey Results (на сайте есть отчеты других лет) и Standish Group 2015 Chaos Report.

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

Во всех этих отчетах Agile-методы рассматриваются без разделения. Но по ним есть отдельная статистика, которую ежегодно публикует Version One,66
  C сайтом что-то случилось совсем недавно, archive.org, показывает и можно искать отчеты – их многие публикуют после выхода


[Закрыть] а пару лет назад ScrumTrek начал публиковать такую же по России (2018, 2019), на которую можно также опираться, и в полной версии, доступной по ссылкам есть цифры о целях и достижениях, которые ставят при Agile-трансформации.

Цифровой мир и цифровизация – в чем разница?

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

Об этом был интересный доклад Алексея Кораблева на SECR-2019. Что интересно, он делился российским опытом по созданию цифровых двойников для производства (мой конспект). И в этом же залоге сделан курс Алексея Боровкова «Технологии Фабрик Будущего» в петербургском Политехе. Кстати, какая-то добрая душа выложила состав курса и ссылки на презентации, конспекты и содержание.

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

Первыми в цифровом мире оказались IT-компании, предоставляющие свои продукты в интернете, сегмент Public Web. Очень быстро появилась продажа других услуг, особенно не требующая контакта с потребителем – билеты, туры, интернет-магазины. При этом помимо каналов продаж возникали чисто электронные площадки и агрегаторы, такие как aviasales, booking или AliExpress, которые принципиально изменяли если не структуру отрасли, то продажи в ней.

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

Даже если компания предоставляет физический, а не электронный продукт, ее прибыльность все больше определяется вовсе не производством этого продукта, а качеством софта и умением с ним работать. Например, авиакомпании сейчас конкурируют не самолетами и летчиками, а логистикой самолетов, которая определяет затраты на стоянку в аэропортах и подобные расходы и программами лояльности, определяющими наполняемость рейсов, а также способностью вписаться в новый маркетинг цифрового мира с его чисто цифровыми площадками. Это надо уметь делать на всех горизонтах: оперативном, работая в высоком темпе с хорошим софтом; тактическом, проводя изменение бизнеса и IT единым проектом, а не по-отдельности, как раньше; и на уровне стратегического управления: стратегия сохранила принципиальное значение, но формулируется совершенно в других терминах.

Пока мы говорили о переходе в цифровой мир, изменяющим компании и вносящим новые аспекты в деятельность, но в целом сохраняющей структуру деятельности и разделение труда. Однако, с переходом в цифровой мир связано еще одно принципиальное изменение, которое принципиально переформатирует отрасль – уберизация, которая переформатирует отрасль, принципиально меняя всю ее структур.

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

Отметим, что Uber – это просто самый громкий пример, ассоциации свободных таксистов и небольших таксопарках во многих городах России прошли тот же путь в местном масштабе, и сейчас в некоторых регионах по-прежнему конкурируют с Яндекс-такси.

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

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

Я думаю, что один из следующих тактов развития – уберизация fashion-индустрии, которая требует более сложной кооперации, чем обычная торговля. Будет четыре игрока: потребитель, стилист, дизайнер и производитель. Для организации кооперации, помимо существующей платформы интернет-торговли, нужна специализированная платформа, позволяющая индивидуализировать модель, разработанную дизайнером, под размеры конкретного покупателя, обеспечив виртуальную примерочную и создав производственные лекала для индивидуального заказа производителю. Это все – чисто технические задачи, и по ним идет интенсивное развитие технологий. Собственно, для плотных и обтягивающих тканей это уже решено, а вот для одежды из свободных и развивающихся тканей виртуальную примерку еще делать не умеют. Ну а дальше надо из дизайна сделать индивидуальные лекала и доставить технологическую информацию для изготовления к производителю, в этом принципиальной сложности нет, это такой развернутый комментарий к заказу, примерно как адрес доставки.

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

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

Удаленная работа и распределенные команды встречаются и во многих компаниях, которые держат постоянный и стабильный штат сотрудников и работают без офиса. Интересно, что на TeamLeadConf-2018 был доклад Алексея Катаева из skyeng в котором он рассказывал, не просто о том, как эффективно организовать такую работу, но и обосновывал, почему удаленная работа эффективнее, чем работа в офисе. Например, при удаленном собеседовании кандидат находится дома, в привычной обстановке, и не нервничает, что позволяет лучше понять его потенциал. В большом посте по итогам конференции есть конспект этого доклада наряду с некоторыми другими.

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


[Закрыть] – организация, в которой несколько десятков менеджеров обеспечивают работу 800 тысяч (да, восьмисот тысяч) исполнителей. О подробностях Ольга Мегорская рассказывала в докладе на Highload-2018 (мой конспект). При этом они начали включать в выполняемые задания и IT, правда, рассказ был только о тестировании, а не о разработке. Кстати, в результате Яндекс отказался от услуг компаний, которые предоставляли ему аутсорс тестирования.

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

И в завершении хочу напомнить, что начале книги мы говорили о том, что цифровой мир нест три основных вызова: Business Agility, Цифровизация и mindset поколения соцсетей.

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

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

В главе «Краткая история IT-менеджмента» я выделял четыре культуры ведения IT-разработки, и после культуры Agile там была культура нового времени, пришедшая примерно в 2012 году. Что же тогда произошло? Примерно в это время развитие public web стало массовым, и в результате применявшиеся там технологии превзошли то, что применялось в корпоративной разработке. Это было замечено, в 2013 Gartner анонсировал на 2014 год новый тренд Web-Scale IT for Enterprise – применение технологий, наработанном в публичном Web для разработки «серьезных» enterprise-приложений.

Как я отмечал в своем отчете о конференции Highload-2019, развитие этого тренда хорошо видно. При этом для банков, которые активно переходили в интернет-пространство, он естественным образом развернулся уже давно. Тинькофф, Сбербанк, Альфа, Райффайзен активно представлены на IT-конференциях. А сейчас эти технологии активно осваивает Retail, в том числе тот, который производит товары, а не просто их продает. На конференции стояли стенды Lamoda, Леруа, Спортмастера и других. Был целый трек, на котором они рассказывали о своих проектах, о переходе с традиционных технологий на современные, и технологический стек там соответствует современному уровню – ClickHouse, Elastic, Kafka, Go и многое другое. И все это неизбежно предстоит другим отраслям.

Однако, public web – это не только технологии, это и свои подходы к ведению проектов. Именно их мы и будем разбирать в этой статье, а в следующей посмотрим, что получилось от их синтеза с классическими технологиями после прихода в корпоративный сегмент. Основой по-прежнему являются Agile-методы, итерационная разработка, кроссфункциональные команды, активные коммуникации и сотрудничество, и весь остальной багаж Agile сохранился и лежит в основе. Что же добавилось принципиально нового?

Сайты ведут постоянную конкуренцию за пользователей. Довольно быстро выяснилось, что хороший дизайн сайтов имеет существенное значение, что дизайн и расположение кнопок и ссылок может в разы или даже на порядки изменить переходы по ним, и это открыло эпоху UI-дизайна, породив соответствующую специализацию. Затем сайты стали интерактивными, и было выяснено, что удобство взаимодействия – далеко не тоже самое, что дизайн элементов и следующий волной была работа с usability. И, наконец, когда взаимодействие с сайтом стало достаточно сложным, выяснился еще один принципиальный момент, отличающий public web от корпоративного софта: пользователя практически нельзя заставить учиться и читать инструкции, он должен осваивать работу на сайте интуитивно. И это породило интерес к изучению интуитивных представлений пользователей – User experience (UX).

Кончено, во многих статьях говорят, что все это давно было в промышленном дизайне, что usability – это та же эргономика оборудования, а просто примененная к сайтам и приложениям, а интуитивное освоение важно не только для сайтов, но и для массовой техники, например, для стиральных машин и телевизоров. Но это правда только отчасти. Потому что если пользователь или предприятие купили какую-то технику, то они, скорее всего, будут ей пользоваться, прочтут прилагаемые инструкции, и если стоимость их значительна, не побегут менять на следующий день просто потому что вышла новая модель. Во всяком случае, 5—10 лет назад так было. И с корпоративными приложениями то же самое: их выбирают одни, а пользуются – другие, и те, кто пользуются – должны изучить.

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

IT наработало свои разнообразные методы изучения пользователей. Многие из них применимы не только к IT-продуктам, поэтому полезно о них знать. Один из мощных подходов – метод персонажей. Изучая своих потребителей, вы делите их на кластеры с характерным поведением, и для каждой из них создаете персонажа, наделяя его личностными качествами – возрастом, полом, образованием, рисуете его портрет. Конкретизация нужна такая, чтобы любой член команды, разрабатывающий новый продукт, мог представить себя на его месте и говорить от его имени. И тогда они могут учесть группу, представленную персонажем, при создании продукта гораздо лучше, чем при более традиционном формулировании требований. Если вы заинтересовались, то про технику персон хорошо рассказывал Юра Веденин в докладе «Persona grata» на AnalystDays-2017.

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

В качестве примера можно рассказать историю Google Glass – очков с встроенным дисплеем. Штука в том, что аналогичные устройства делали много компаний, но все они шли по одному и тому же пути: сначала делали тяжелый прототип, вкладывая довольно много средств в разработку, потому пытались привести его к приемлемому весу и габаритам и терпели неудачу. А Google пошел по другому пути: после того, как предлагали принципиальную архитектуру, конструкторы примерно оценивали узлы и делали прототип из пластилина, проволоки и подобных материалов, и проверяли: человек в принципе может это носить или нет? И потому много идей они отсеяли быстро и дешево на раннем этапе – что и принесло успех. Здесь надо отметить, что четкое понимание необходимости следовать за потребителем и его изучения пришло не сразу. Инженерам свойственна иллюзия, что хорошая техническая идея будет оценена пользователями и обречена на успех, что она «сама себя продаст». Это – не так. Тем более, что разработчики, оценивая идею, часто судят «по себе». Так же инженеры склонны думать, что хорошая идея обязательно будет оценена пользователями и «сама себя продаст». Это – иллюзия.

Те, кто следил за развитием Google, помнят, что после первоначального успеха компания разрабатывала множество разнообразных продуктов и сервисов. А потом, в начале 2010-х их количество начало сокращаться, в основном как раз потому, что продукты оказались вовсе не столь востребованы. А еще потому, что при их создании разработчики вообще не подумали о монетизации продукта – инженерам это свойственно. И тогда пришли менеджеры и объяснили разработчикам, что эти факторы учитывать необходимо. Изменения оказались не простыми, эту историю можно прочесть в посте Джеймса Уиттакера, одного из разработчиков в Google с рассказом о тех изменениях (2012).