Оглавление

Об этой книге

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

У меня есть картина происходящих изменений, которую я рассказываю в статьях и выступлениях. Статья «Agile и бирюзовые организации — ответ менеджмента на вызовы новой промышленной революции» была опубликована в сборнике ПИР, а статья «Бирюзовые организации и agile: какие полезные практики стоят за хайпом», опубликованная в сентябре 2019 на портале vc.ru вызвала большой отклик читателей. Но материалов — много, полная сборка слайдов для выступлений превысила 200, в одной статье или лекции их можно изложить лишь поверхностно. И поэтому осенью 2019 года я решил написать серию статей. Это было успешно проделано, первая статья была опубликована на vc.ru 22 ноября 2019, а последняя в серии 52-я статья 10 июня 2020 года.

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

Однако, зимой 2022 года я готовил курс по менеджменту цифрового мира, и помимо лекций необходимо учебное пособие. статьи могут выступать в этой роли, их надо собрать в единый файл. Поэтому я наступил на горло своему перфекционизму, взял исходные тексты статей, которые готовил в Word и поверхностно прошел по ним, заменив в ссылках «статьи» на «главы», убрав в начале каждой статьи изложение предыдущего и внеся другие небольшие редакторские правки. При этом, возможно, был утерян ряд правок, которые я делал непосредственно при публикации на портале. И получилась эта книга.

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

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

И с 2017 года я, продолжая работать над ИТ-проектами, стал консультантом по применению Agile-методов и других методов самоуправления — бирюзовыми организациям, холакратии, социократией за пределами ИТ, навигатором по миру нового менеджмента цифрового мира. А также рассказываю ИТ-шникам и консультирую ИТ-компании по альтернативным моделям самоуправления, спиральной динамике и другим моделям soft skill, необходимым в современном менеджменте. Опыт работы аналитика позволяет объяснять это на понятном языке, приземлять на знакомый материал. Подробнее — на моем сайте http://mtsepkov.org, там более 230 моих статей и выступлений по разным темам и много других материалов.

Вызовы цифрового мира

Приход цифрового мира

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

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

И если с этой точки зрения посмотреть на третью, научно-техническую революцию, которая связывается с развитием науки и техники, включая появление компьютеров примерно в 1960—1990, то можно отметить, что ее результаты были использованы в рамках ранее сложившихся способов организации производства, и с этой точки зрения ее нельзя считать завершенной. Именно разворачивающаяся сейчас цифровая революция призвана завершить преобразования, которые включают в себя не только заводы-роботы и управляемые автопилотом автомобили, но и персонализированное производство вместо типового, а также принципиальное изменение способов организации бизнеса на основе цифровых платформ, которые мы сейчас видим в Uber, Aliexpress и других. Отметим, кстати, что английские источники, такие как wikipedia.org/wiki/Technological, revolution#Potential, future, technological, revolutions не присваивают научно-технической революции отдельного номера и относят ее на более ранний период, а третьей промышленной революцией считают именно цифровую революцию, начавшуюся в 1975 и продолжающуюся сейчас.

Об истории промышленных революций сопоставлении их между собой, выявлении общей логики развития и формированием на их основе картины будущего много и интересно рассказывает Петр Щедровицкий. У него есть супер-короткий 12-минутный доклад об этом, и много развернутых выступлений на его сайте https://shchedrovitskiy.com/lekcii/, включая подробный разбор пути России. И тех, кому эта тема интересна, я рекомендую смотреть и разбираться.

Цифровой мир: от физического труда — к умственному

Наиболее очевидный вызов цифрового мира для менеджмента — это перейти от организации физического труда, task work, к организации труда умственного, knowledge work. Сила этого вызова стремительно возрастает по мере цифровизации бизнеса.

Традиционный менеджмент, сформировавшийся в ХХ веке, в фазе завершения второй промышленной революции и последовавшем после него периоде устойчивого развития, основан на регламентах, нормировании деятельности через инструкции и компетенции. Он представлен в трех основных вариантах: Process, Project и Case management. Уверенный результат достигается только в случае Process management, однако сама организация процесса и разработка регламентов опирается на компетентность организатора, а не на технологию управления. В случае Project management на компетентность участников опираются фазы анализа и создания самого проекта, а для Case management требуется высокая компетентность во всей деятельности.

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

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

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

Питер Друкер начиная с 1980-х анализирует изменения и вызовы, которые несет менеджменту автоматизация рутинного труда и переход к работе, связанной со знаниями, посвящая этому главы в своих книгах. А в начале века написал об этом отдельную книгу «Менеджмент. Вызовы XXI века». Основной вызов состоит в том, что все большая доля деятельности будет требовать от сотрудников решений «менеджерского» уровня. В традиционном менеджменте такие решения требуют личных способностей и опыта, и доступны ограниченному кругу сотрудников, получивших соответствующее образование и прошедших отбор. Они медленно накапливают опыт и компетенции, двигаясь от решения простых задач к более сложным. Если все простые задачи решают компьютеры и роботы, такой путь становится невозможным. В обществе, управляемом знаниями, области высокой компетентности расширяются и охватывают всю деятельность. С помощью традиционного обучения сформировать новые компетенции также невозможно из-за высокого темпа изменений: традиционные курсы требуют для становления 5—7 лет минимум, и потому оказываются устаревшими уже в середине создания.

Почему в области умственного труда не работают регламенты? Потому что от выбора метода решения принципиально меняется его трудоемкость, а инструкцию по выбору написать нельзя. С этим сталкивался всякий, кто в институте решал задачи аналитического интегрирования. Или увлекался задачами на геометрические доказательства в школе — одно удачное дополнительное построение может сделать нерешаемую задачу очевидной. И решения о выбранном методе принимает исполнитель, который делает задачу, более того он принимает не одно, а десятки таких решений, почти на каждом шагу — потому что когда метод не дает результата тоже надо принять решение — настойчиво пробовать дальше использовать тот же метод или остановиться и попробовать другой. И потому эти решения не могут быть переданы менеджерам или опытным сотрудникам — тогда, по сути, решать задачу будет другой человек. Впрочем, менеджерам для решения профессиональных задач не хватает компетентности и знаний предмета. О проблемах менеджеров, которые взялись принимать профессиональные решения в современном мире, есть замечательная серия комиксов Скотта Адамса про Дильберта, одну из которых я привожу как иллюстрацию. Кто не знаком с этим феноменом — гуглите и получайте удовольствие.

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

Заметим, что образ организации с самореализующимися и развивающимися сотрудниками очень напоминает ту идеальную картину, о которой пишет Фредерик Лалу, рассказывая о бирюзовых организациях. Сам Друкер не пишет, как будет устроена такая организация, более того, он полагает, что существующий на момент написания книги менеджмент не знает этих ответов. Питер Друкер — один из создателей менеджмента и до конца жизни оставался действующим теоретиком менеджмента, поэтому его трудно заподозрить в незнании каких-то секретных методов менеджмента, которые эту проблему решат.

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

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

Поколение соцсетей — новый mindset цифрового мира

Главное изменение, которое несет промышленная революция — конец индустриального общества. И это изменение тоже давно предсказано. Почти 40 лет назад, в далеком 1980 году, Элвин Тоффлер в книге «Третья волна» писал о неизбежности принципиальных изменений, показывая, что сложившиеся механизмы и мировоззрение индустриального общества будут несовместимы с тем новым, что несут технологии. И делал вывод о кардинальных изменениях, переосмыслении понятий и ценностей, которые приведут к радикальному изменению бизнеса и организаций, семьи, государства и всего человечества.

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

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

Однако под поверхностью лежит еще один слой — изменение шаблонов успешного лидерства. Гэри Хэмел (Gary Hamel) в статье «The Facebook Generation vs. the Fortune 500», опубликованной в The Wall Street Journal (2009) показал, что способы достижения успеха на интернет-форумах и группах в соцсетях противоречат традиционным шаблонам поведения, ведущим к продвижению в корпоративной культуре. Их отличия столь велики, что новое поколение в статье было названо в честь Facebook[1].

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

Кстати, когда я рассказал об этой статье в беседе на HR Media. Ведущие заинтересовались, нашли статью и сделали краткое изложение содержания по-русски.

— Все идеи конкурируют на равных. В Web, каждая идея имеет шанс получить продолжение или нет, и никто не имеет права убить идеи или подавить их в обсуждении. Идеи усиливаются на основе их сути, а не политической власти их авторов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Культура и процессы — две стороны компании

Мы уже разобрали, что принципиальным изменением, которое приносит цифровой мир, является изменение мировоззрения, которое уже ярко проявлено как mindset поколения соц. сетей. И это означает, что менеджмент не может ограничиваться организацией процессов, а должен уметь работать с культурой компании.

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

И тут уместно привести схему Марка Розина «Кораблик», наглядно показывающую разделение компании на бизнес-процессы и культуру, и два паруса, которые их двигают: целеполагание и управление изменениями. На рисунке поверх этой схемы показано отражение в этих составляющих таких ключевых факторов организации как гибкость, эффективность и вовлеченность.

— Гибкость означает, что процессы адаптивны и быстро перестраиваются, и в них встроена обратная связь от клиентов. Но эти процессы не будут работать без культуры жизни в эпоху перемен, поощрения инициативы и чуткости к нуждам клиентов.

— Эффективность означает, что процессы измеримы по стоимости и создаваемой ценности и оптимизируются. И она требует культуры инициативного поиска мест улучшений в процессах.

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

Подумайте, когда вы анализируете проблемы своей компании, или планируете, проведение изменений, вы всегда думаете про обе стороны медали, или только про одну? В жизни достаточно часто встречаются те, кто видит только одну сторону. Если видят только процессы, то возникает типичная ситуация, когда инициативы изменений саботируются и вязнут в культуре компании, и именно о такой ситуации Питер Друкер как-то заметил «культура ест стратегию на завтрак». Или появляется сожаление о природе человека: «каждый раз, когда мне нужна пара рук, к ним зачем-то прилагается голова». Эту фразу я услышал в одном из выступлений и выступающий приписывал ее Форду, она достаточно хорошо характеризует тех, кто мыслит процессами. Но не менее часто бывает и обратное, когда призывы о движении к великим целям и ежедневной работе не поддерживаются адекватной организацией процессов, и в результате все движение вязнет в хаосе несогласованных действий.

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

Деструктивные варианты культуры компаний, бессмысленный мир корпораций хорошо описаны в книге Дэйва Логана, Джона Кинга и Хэли Фишер-Райт «Лидер и племя». И там же описан выход в здоровую культуру через обретение смысла. Однако, сейчас этого уже недостаточно, потому что поколение соцсетей несет другие ценности и смыслы. И единственный образ правильной компании со здоровой культурой размывается, у него получается много трактовок. Возможно, когда вы выше читали, как я в этой статье определяю гибкость, эффективность и вовлеченность, то не согласились с тем смыслом, который я вложил в эти понятия. И это — совершенно нормально. На самом деле я знаю не один и не два, а более пяти вариантов наполнения этих понятий смыслами. И не только для этих понятий — изменяется взгляд на лидерство, справедливость, назначение и роль бизнеса и практически все остальное. Хорошая иллюстрация этих изменений — уже упоминавшиеся комиксы Скотта Адамса про Дильберта. Вот пример, как воспринимается лидерство. Заметим, что при этом люди прекрасно знают правильные слова, и если надо — то будут их говорить. Но вот как они при этом будут действовать — тоже понятно.

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

Кстати, в уже упомянутой книге «Лидер и племя», описывающей пять корпоративных культур, авторы тоже столкнулись с этим феноменом. Они первоначально выделили и описали четыре культуры, три негативных варианта и один позитивный, компанию, которая сплочена и сотрудничает в достижении общей цели и потому уверенно побеждает конкурентов. А потом в компании Amgen они обнаружили культуру, которая не укладывалась в эту схему, но при этом была очень крутой: компания не боролась с конкурентами, а успешно изменяла мир к лучшему. И они два года исследовали ее, сочтя необходимым задержать выход книги. И это как раз проявление культуры компании, адекватной приходящему новому mindset. Впрочем, по одному примеру хорошего представления о конструкции новых компаний авторам получить не удалось. Но сейчас их становится больше. И мы еще вернемся к конструкции организаций будущего, когда в этой серии статей доберемся до разбора бирюзовых организаций. А пока я хочу порекомендовать книгу «Лидер и племя» тем, кто еще ее не читал. Ну и заодно порекомендовать свой разбор этой книги, включающий сопоставление с бирюзовыми организациями Фредерика Лалу.

Так же я хочу сказать, что многие почему-то полагают, что работа с культурой компании — это некоторое шаманство, или искусство, или непонятные психологические манипуляции. Это не так, работа с культурой компании вполне освоена в рамках менеджмента. Интересующимся я хочу порекомендовать книгу Марка Розина «Успех без стратегии» (мой конспект, одобренный автором), в пятой и, особенно, шестой главах Марк хорошо раскрывает технологичную работу с культурой. Просто раньше, в индустриальном мире, для этой работы можно было использовать более простые модели, не учитывающие формирующееся мировоззрение цифрового мира. А теперь нужны современные модели, такие, как модель Спиральной динамики, раскрывающие логику изменения систем ценностей. И эта модель тоже будет детально рассмотрена далее.

Три вызова цифрового мира

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

— Business Agility — необходимость для компаний быстро изменяться в ответ на высокую неопределенность и скорость изменения рынков в VUCA-мире. Изменения правил и регламентов не успевают за изменениями мира. Массовых курсов, обучающих эффективно действовать в условиях высокой неопределенности тоже нет.

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

— Mindset поколения соцсетей: работа должна давать фан, драйв и самореализацию, человек должен быть счастлив на работе. Организация должна вовлекать людей с таким представлением о жизни, иначе останется без сотрудников.

Разные отрасли развиваются в разном темпе, поэтому сила вызовов различна. И даже на разные подразделения одной организации эти вызовы могут действовать в разную силу. IT их ощутило уже более 20 лет назад, и Agile возник как ответ на них, это мы будем подробно разбирать в отдельных статьях дальше. И уже лет 5—7 назад свободный график, гибкая организация и отсутствие бюрократии стали стандартом де-факто не только в небольших стартапах и IT-компаниях, но и в IT-отделах крупных корпораций и банков. В 2012 я слышал, как руководители проектов Сбербанка, в котором тогда IT было организовано традиционно, жаловались, что не могут найти опытных разработчиков на интересный проект, несмотря на зарплату +30% к рынку: как только те узнавали, что работа с 10 до 17, и много бюрократии — они теряли интерес к предложению.

Сейчас в уже говорят о новом социальном контракте сотрудника, который приходит на смену старому «зарплата в обмен на компетентное выполнение своих обязанностей». Этот контракт звучит так: «искренняя работа на цели компании в обмен на условия для счастья на работе». И это — всерьез, услышав на AgileDays-2019, как Александр Горник говорит об этом контракте и призывает «не стесняйтесь требовать от компании выполнения ее части контракта», я написал об этом статью. И меня позвали сделать об этих изменениях доклад на конференцию РИТ++, собирающую более 3000 участников, где счастью на работе был посвящен отдельный трек. Конечно, это пока первые ласточки, но ориентироваться на темпы, которыми в IT распространялся Agile, то можно предположить, что лет через пять или чуть больше новый контракт распространится по IT, включая IT-отделы корпораций, заинтересованные в квалифицированных разработчиках. А практически это означает все корпорации. Потому что даже авиакомпании сейчас конкурируют не самолетами и не пилотами, они конкурируют бонусными программами привлечения пассажиров и логистикой самолетов, снижающей оплату стоянок в аэропортах и повышающей часы полета, а и то и другое обеспечивается IT-программами.

Если учесть, что пять лет на изменения в большой компании — это очень быстро, то получается, что готовиться к этим изменениям надо уже сейчас, ну, через пару лет максимум. Тем более, что Agile уже завоевывает не только IT, но и R&D отделы корпораций, да и на основном производстве тоже применяется. Например, на AgileDays-2019 был доклад о применении его методов на литейном заводе, и делал его не Agile-коуч, а заместитель генерального директора. И было много других докладов, интересующиеся могут посмотреть программы конференций или мои репортажи с конспектами докладов можно по ссылкам http://mtsepkov.org/AgileDays-2019 http://mtsepkov.org/AgileDays-2018 http://mtsepkov.org/AgileBusiness-2018.

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

На этом я завершаю первую главу, которая была посвящена вызовам нового мира. Вторая глава будет рассказывать про Agile — не только про процессы и методы, но и про логику развития, и про изменение культуры IT-проектов в целом, включая современный этап. И это может быть интересным не только тем, кто хочет применить Agile в своей компании, но и тем, кто активно взаимодействует с IT-шниками и хочет понять их логику управления проектами. Отметим, что вокруг Agile-методов сейчас множество мемов и профанаций, вызванных общим дефицитом компетентных специалистов, так что разбираться самостоятельно — полезно. Я знаком с Agile более 10 лет, и активно участвовал в сообществе AgileRussia с самых первых собраний в 2009.

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

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

 Компания Мета, владелец продукта «Facebook» (и «Instagram»), 22.03.2022 признана в России экстремисткой за их политику и практику модерации контента. При этом отдельно оговорено, что решение не ограничивает использование продуктов Мета физическими и юридическими лицами для не запрещенной законом деятельности. Правда, это не повлекло снятия ранее установленной блокировки доступа, а при упоминании названия требуется сноска, подобная этой. Подробности — в решении по делу 02—2473/2022 Тверского суда города Москвы.

Agile

Краткая история IT-менеджмента

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

Отмечу, что я, естественно, не первый, кто обращается к истории развития IT-менеджмента и показывает ее как историю развития культур. В 2008 была опубликована книга Энтони Лаудера «Культуры программных проектов». В духе времени он решил не публиковать бумажную книгу, а выложил текст в интернете. Перевод на русский был сделан Альбертом Мустафиным и выложен в блоге happy-pm по главам и целиком в pdf. А здесь рецензия Стаса Фомина, от которого я в свое время узнал про книгу.

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

Мое деление культур — отличается от того, что увидел Лаудер. В моей классификации тоже четыре культуры, но она доведена до нашего времени, и переход к последней около 2012 года, уже после публикации книги Энтони. Моя периодизация культур представлена на схеме.

Каждая культура изменяет не только способ реализации проекта и управление им, она также расширяет рамку проекта. Эпоха НИОКР. Это период становления IT-отрасли, программы разрабатывались в университетах и институтах так же, как ведут конструкторские работы. Они и сами были частью более масштабных проектов, обеспечивая расчеты для военной, космической, атомной и других отраслей. Дело было новое, и основная проблема — добиться, чтобы программа работала, выдавала правильные результаты.

Эпоха RUP — классическое управление проектами. По мере развития отрасли возрастала потребность не просто разрабатывать программы, а делать это с предсказуемыми сроками и затратами, в соответствии с планами. Это пробовали делать методами классического менеджмента, и на этом пути были многочисленные неудачи, а успех так и не был достигнут. И в принципе в 1980-х уже поняли причину: ключевым фактором успеха IT-проектов являются не процессы, а человеческий фактор. Но плохие новости редко принимают и в 1990-е годы был предпринят значительный рывок в этом направлении — были собраны реальные гуру IT и создан Rational Unify Process (RUP), из которого позднее в значительной мере вырос современное проектное управление с его руководством PMBOK (Project Management Body of Knowledge). Но успеха достигнуто не было, предсказуемого результата получить не удалось, несмотря на многократно возросшую стоимость тяжелой процедуры.

И как альтернатива тяжелым методам RUP на рубеже 21 века появились легкие Agile — подходы, наступило время Agile и Scrum — первого из Agile-методов. который и принес ему успех. Формально зарождение Agile — 2001, год подписания Agile-манифеста http://agilemanifesto.org/ (на русском). Идеи очень простые: раз человеческий фактор — главное, то построим процесс на сотрудничестве людей, а не на регламентах. А раз результат все равно гарантировать нельзя — будем наблюдать за продвижением к нему.

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

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

Все это определило успех Agile, сначала он завоевал небольшие компании, а в конце нулевых пошел в крупные компании и IT-отделы корпораций. К тому времени, помимо Scrum был Kanban, гибридный Scrumban, и еще ряд методов и практик, несущих больше IT специфики и потому менее известных (XP, FDD, TDD, DDD и другие).

По мере того, как IT все больше входило в жизнь компаний и обеспечивало их бизнес-процессы, произошел следующий сдвиг рамки проекта: результатом проекта должно быть не просто разработка и внедрение софта, а решение в результате внедрения конкретных бизнес-задач и достижение возможностей бизнеса, при чем достижение результатов определяется не формальными критериями, а удовлетворенностью стейклолдеров. Принципиально изменился характер задач, которые бизнес ставит перед IT: не «разработать конкретный набор фич», а «доработать продукт так, чтобы доля занимаемого им рынка в Латинской Америке возросла с 3 до 7%», не «внедрить новую систему управления складом», а «добиться вместе с логистиками, чтобы пропускная способность склада в пиковую нагрузку увеличилась вдвое». И это по времени совпало с развитием интернет и ориентацией для продукты для конечного пользователя, а не для компаний, что вызвало свое семейство методов ведения проектов, основанных на User Experience. Которые, кстати, сейчас становятся актуальными и в других отраслях. Эта культура пока не имеет общего названия, потому что она не осознается как нечто цельное. Однако, составляющие ее концепты широко известны: UX, продуктовый подход, DevOps. Поэтому на слайде она просто обозначена как «Новое время».

Таким образом, каждая культура имела свои представления о том, что такое хороший проект и качественный продукт, которые кратко отражены выше на схеме. Но самое главное отличие возникает, когда что-то пошло не так, когда в ходе разработки оказалось, что проект невозможно сделать в запланированные сроки и бюджеты, или что разрабатываемая система не будет решать ту задачу, которую на нее возлагали. Культуры регулярного менеджмента предлагают заказчику смириться: НИОКР — потому что всякие исследования и конструкторские работы могут быть окончиться неудачей, а RUP — потому что заказчик ведь сам согласовал то задание, которое было выполнено и возможные риски. Естественно, исполнитель всегда готов открыть новый проект и попробовать еще раз решить задачу с учетом полученного опыта. Но после оплаты ранее сделанного, а процесс устроен таким образом, что неудача обнаруживается близко к завершению. Типичная ситуация в IT — когда после того как бюджет израсходован на 90% выясняется, что задача сделана наполовину, и надо еще столько же. И так — несколько раз. Agile не дает гарантии результата, но в нем это явно оговорено, в то время, как регулярный менеджмент результат обещает. Однако он предлагает заказчику постоянно следить за движением проекта и корректировать направление, чтобы прогнозы становились более реалистичными. А еще — начинать с зон наибольшей неопределенности, а не откладывать их на потом, чтобы, встретив там существенные трудности, заказчик мог быстро свернуть проект — это принцип Fail fast. А современные подходы, помимо раннего обнаружения проблем и культуры постоянных экспериментов и проверки гипотез нацелены на партнерство IT и бизнес-заказчика в решении проблем и достижении возможностей.

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

Развитие и провал регулярного менеджмента в IT

Сейчас я подробно рассмотрю развитие регулярного менеджмента в IT и причины его провала. Как пишет Эдвард Йордан в книге «Смертельный марш», история IT — это история безнадежных проектов. К этой книге мы еще вернемся, а пока отметим, что с развитием цифровизации эта же ситуация воспроизводится в других отраслях, и потому этот материал интересен не только IT- шникам. Тем более, что миф о том, что существует правильный способ выполнения IT-проектов, обеспечивающий гарантированный результат, и он точно известен компетентным инженерам, которых просто надо найти, является чрезвычайно распространенным и заманчивым, и в эту ловушку неоднократно попадались и продолжают попадаться и те, кто заказывает IT-проекты, и те, кто их делает.

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

Что касается организации работ, то характерную метафору для описания команды разработки дал Фредерик Брукс — бригада главного хирурга, состоящая из компетентных специалистов разных областей, дополняющих друг друга, всегда готовая к проведению сложных операций и успешно их выполняющая. И сразу понятно, что успешные разработчики — специалисты высокого класса, настоящие профессионалы, которых не может быть много. Правда, проблема заключалась в том, что практически такую команду, создающую софт примерно с такой же уверенностью, с которой бригада хирургов проводит операции собрать было невозможно. Очень много проектов в этой метафоре квалифицировались как экстраординарные операции, успех которых не гарантирован.

По мере того, как потребность в IT-проектах возрастала, а область использования IT начала включать не только военные и научно-исследовательские проекты, но и коммерческие проекты, росло желание каким-либо образом обеспечить результат. И менеджмент пошел по известному ему пути ввода правил и регламентов, ресурсного планирования, нормирования работ и учета рисков. Вот тут-то проявилась особенность IT — регулярный менеджмент плохо работает для организации умственного труда. Как общий вызов современности мы ее обсуждали в ранее, в главе «Цифровой мир: от физического труда — к умственному». А тогда, в 1960-х она ярко проявилась в проекте IBM разработки новой операционной системы OS/360. Результаты попыток применить привычные менеджменту подходы в IT-разработке были хорошо проанализированы Фредериком Бруксом, который как раз руководил этим проектом, в книге «Мифический человеко-месяц» (1975), обобщающей опыт многих проектов и ставшей бестселлером. В частности, он сформулировал парадоксальных закон «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше», и этот закон не является единственным результатом.

Собственно, в чем смысл подхода проектного управления? В том, чтобы всю неопределенность движения по V-диаграмме перенести на стадию проектирования, а то, что не получается — явно выделить как риски, оставив на стадии разработки только типовые операции с предсказуемой трудоемкостью. Тогда после завершения проектирования ход разработки становится предсказуемым, и менеджеры смогут управлять им в классическом треугольнике объем (scope) — сроки — стоимость в одном из его вариантов.

Почему это не работает? Причина — в том, что работа в IT нормируется очень плохо, скорость ее выполнения существенно зависит от человеческого фактора. Не просто от конкретных людей, а от людей в конкретных условиях, знания о том, как человек раньше решал аналогичные задачи не помогает предсказать, как он решит очередную. Влиянию человеческого фактора на ход проектов посвящена классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

Почему же построить процесс проектирования самолетов, исключив человеческий фактор, так, что после принципиального проектирования новый самолет можно контрактовать Боингу удалось, а вот решить аналогичную задачу в IT — не получается? Причина заключается в природе IT-разработки. Это тоже было выяснено давно, этому посвящена статья Джека Ривза (Jack W. Reeves) «What is software design» (1992, перевод). Дело в том, что при сопоставлении разработки софта с НИОКР в других отраслях, например, проектирование самолетов, мы должны отнести написание кода не к производству, а к низкоуровневому проектированию. То же, что делают заводы на опытном производстве в IT делает среда разработки, собирая проект, делает быстро и дешево и потому ошибки проектирования не критичны, их исправляют не тщательной предварительной проработкой, а тестированием и отладкой. Это сильно дешевле статистически, но делает выполнение конкретной задачи слабо предсказуемым, вернее, получается распределение с жирным хвостом, так, что для срок для 90% уверенности в три раза превышает мат. ожидание. Об этом был интересный доклад Андрея Бибичева «Пуассоново горение сроков». Схематично это изображено на рисунке. А я отмечу, что задачу IT-разработка оказалась как раз той областью, где Боинг тоже постигла неудача: множество скандалов вокруг его самолетов связаны как раз с бортовым софтом.

Впрочем, и менеджеры и инженеры редко верят в то, что какие-либо вещи являются невозможными. И невзирая на статистику проектов и объяснение причин в 1990-х была предпринята масштабная попытка создать предсказуемый процесс. Компания Rational Software собрала гуру IT-разработки и поставила такую задачу. В результате появился Rational Unify Process (RUP), универсальный процесс, включающий все возможные варианты, из которого надлежало выбрать нужное для проекта и использовать. В дальнейшем он послужил основой PMBOK. Эксперимент окончился неудачей: стоимость разработки с соблюдением всех процедур возросла многократно, а гарантий успеха — не получилось.

Одним из громких провалов проектов в IT является история нового денверского аэропорта (1993—1995). Его пуск в эксплуатацию был задержан на полтора года из-за того, что не была готова система управления автоматической доставкой багажа к самолетам. При этом проектировщики аэропорта не заложили возможности доставлять багаж вручную: доставка должна была осуществляться по подземным туннелям, диаметр которых не позволял использовать средства с водителем. Представьте размер убытков: все эти полтора года новый построенный аэропорт не могли запустить, а старый, в центре города и уже проданный инвесторами — продолжал работать. История рассказана в книге Тома ДеМарко и Тима Листера «Вальсируя с медведями», а я ее услышал от авторов, когда они в 2012 приезжали в Москву. Еще одна провальная история регулярного менеджмента в IT — свежая, 2013 год — это история ObamaCare. Создание сайта для регистрации страховок национальной программы HealthCare.gov по первоначальным оценкам требовало 94 млн$, еще до старта работ сумма выросла до 292 млн$, а фактически сайт обошелся в 1.7 млрд.$. И при этом на момент старта сайт был практически не работоспособен: при планируемой нагрузке в 60000 посетителей тесты показывали максимум 1100, только 1% посетителей в первом месяце смогли завершить регистрацию из-за множественных ошибок и так далее. Интересно, что провал проекта в некоторых статьях приписывают как раз применению agile-методов отдельными подрядчиками. Но факт состоит в том, что это — государственный проект, в нем участвовало более сотни подрядчиков, генподрядчиком была одна из крупных IT-компаний с мировым именем, и его вели по тем методикам проектного управления, которые были приняты в США как стандарт, там есть регулирование. И блистательно провалился. Провал имел политические последствия и Обама после него озверел и организовал US Digital Service, который начал разрабатывать нормативку для ведения госпроектов по гибким методологиям. Историю я услышал в 2015 на AgileKitchen по применению Agile в госпроектах (мой отчет), а в комментариях к моему посту (Agile — это Карнавальная ночь как способ производства),подробно разбирались со ссылками на источники — люди хотели быть уверенными в достоверности. Потому что подобные истории подрывают веру в проектный менеджмент, что для многих людей является потрясением основ…

Непредсказуемость IT-проектов имеет еще одну причину — быстрое развитие технологий. Есть шкала Technology rediness level, разработанная NASA для оценки технологий, закладываемых при проектировании космических кораблей. И для гарантии детального проектирования и разработки самолета Боинг разрешает закладывать при принципиальном проектировании в новый самолет со зрелостью не ниже 8 из 10. Если же мы посмотрим на современную IT-разработку, то там активно используются технологии уровня 4—5. И не из-за тяги к новизне и риску, а потому, что технологии не успевают созреть, и без этого мобильные телефоны оставались без софта несколько лет после изготовления, а новые возможности железа не были задействованы софтом. Как легко догадаться, такая картина невозможна. А использование незрелых технологий чревато непредвиденными рисками при осуществлении проекта, потому что задачи, которые оценивали как легко решаемые с помощью каких-либо новых фреймворков или библиотек, вдруг оказываются сложными, и не потому, что сама технологий не подходит в принципе, а потому что в рамках фреймворка эта задача еще не является стандартной, и надо не просто воспользоваться готовой библиотекой, а дописать эту библиотеку в процессе решения. Кстати, сейчас это достаточно распространено: вендоры не успевают за развитием технологий, поэтому по многим новым подходам, например, реактивному программированию, разработчики используют open source библиотеки, дорабатывая их в ходе проекта.

Я хочу в конце вернуться к тому, с чего начал — к книге Эдварда Йордана «Смертельный марш». Эта книга написана в 1997 и подводит почти 40-летний опыт IT-менеджмента, и он заключает, что «безнадежные проекты являются нормой, а не исключением», несмотря на то, что каждое новое поколение менеджеров, вооружаясь новыми методологиями, обещает этого не допустить. Безнадежный проект — это такой, вероятность провала которого более 50%, иногда существенно, ввиду дефицита одного или нескольких ресурсов в два или более раз по сравнению с нормальными оценками или по другим причинам. Как он пишет, наиболее простой ответ на то, почему так происходит, состоит в том, что люди — идиоты. Но поскольку «слишком тягостно представить себе, что вы идиот, окружены идиотами и руководят вами идиоты», то он приводит более развернутый список причин, по которым появляются безнадежные проекты.

— Политика, политика, политика

— Наивные представления маркетинговых служб, высшего руководства, менеджеров проекта и др.

— Наивный оптимизм юности: «Мы сможем сделать это за выходные!»

— Менталитет первопроходцев у неопытных предпринимателей

— Менталитет «Морского Корпуса» (Marine Corps): Настоящие программисты не нуждаются в сне!

— Высокая конкуренция, порожденная глобализацией рынков

— Высокая конкуренция, вызванная появлением новых технологий

— Сильное воздействие неожиданных правительственных решений

— Неожиданный и/или незапланированный кризис — например, ваш поставщик оборудования/ПО только что обанкротился, или три ваших лучших программиста только что умерли от бубонной чумы

И далее он подробно разбирает эти причины и логику развития проекта. И, поскольку попытки сделать проекты в логике «настоящего проектного управления» не прекращаются до сих пор, эта книга тоже сохраняет актуальность.

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

Agile — ответ IT на вызовы цифрового мира

Agile появился в IT рубеже 21 века в IT как альтернатива регулярному менеджменту в ответ на вызов цифрового мира: обеспечить организацию проектов умственного труда при дефиците кадров и высокой динамике развития. Я хочу подчеркнуть, что Agile — он не про то, как сформировать индивидуальную траекторию развития компании, о необходимости которой я писал ранее, а он про то, как по этой траектории двигаться. Потому что старые способы движения, которые предлагал, говорил регулярный менеджмент — точно не подходят, принципиальную неспособность регулярного менеджмента организовать умственный труд.

Итак, в 1980-х при анализе опыта IT было осознано, что ключевым фактором успеха IT-проектов является человеческий фактор, а не организация процессов. Об этом — классическая книга Тома ДеМарко «Peopleware» (1987). В 1990-х была предпринята попытка найти решение хотя бы для крупных проектов, в которых стоимость не имеет принципиального значения, гуру IT разработали Rational Unify Process (RUP), но даже для них гарантировать успешную реализацию в соответствии с планами не получилось. Параллельно в с 1980-х шло интенсивное развитие персональных компьютеров, которые стали доступны средним и мелким фирмам. Это вызвало большую потребность в разработке софта для автоматизации бизнес-процессов. учитывающих специфику конкретного бизнеса — обобщенных конфигурируемых решений, подобных 1C тогда не существовало. При этом такие проекты обладали значительно более скромными ресурсами. Кризис доткомов также ярко показал необходимость найти решение для скромных проектов и стартапов. Отметим, что автоматизация мелкого и среднего бизнеса, а также разработка для стартапов имеют принципиальную особенность: среда, в которой должен работать софт, сильно изменяется за время разработки. Если вы принесли продукт, разработанный по требованиям годовой давности, он оказывается никому не нужен, в отличие от военных или научных проектов, касающихся моделирования физического мира или автоматизации крупных корпораций, процессы в которых относительно стабильны. По сути, это — можно рассматривать как предвестие VUCA-мира, в котором IT начал существовать.

Каким же образом Agile удалось ответить на вызовы организации умственного труда и разработке для VUCA-мира? А очень просто: раз ключевым фактором успеха IT-проектов является человеческий фактор, значит не надо ставить на процессы, а надо сделать ставку на команду, которая сама организует свою работу. А чтобы команда объединилась в движении к общим целям, необходимы ценности, которые послужат основой. Так появился Agile-манифест (2001) (на русском). Заметим, что ответ ассиметричный: проблема лежит в области процессов, а решение — в области культуры. Это явно видно на схеме, приведенной ниже, где конструкция Agile помещена на схему кораблика.

Итак, ценности Agile-манифеста:

— Люди и взаимодействие важнее процессов и инструментов

— Работающий продукт важнее исчерпывающей документации

— Сотрудничество с заказчиком важнее согласования условий контракта

— Готовность к изменениям важнее следования первоначальному плану

Что тут важно? Как я показывал ранее, есть системные причины, по которым IT-проекты не развиваются в соответствии с планами. Столкнувшись с такими ситуациями, менеджеры шли по понятному им пути — пробовали взять под контроль все что только можно. Но это — не помогало. И в результате в других проектах жесткий контроль пробовали вести с самого начала. И Agile-манифест родился именно как противодействия этим бессмысленным попыткам тотального контроля. И поэтому он делает особый акцент как раз на ценности сотрудничества и результативности, в противовес тем формальным вещам, на которые делали акцент менеджеры озабоченные, быть может, не столько успехом проекта, сколько попытками избежать ответственности за неудачу. Есть еще один аспект, связанный с американским концептом универсального менеджмента, не зависящего от предметной области, который лучше всего выразил MBA. Правая, менее важная часть ценностей представляют собой то, что не зависит от предметной области, и с чем менеджеров учили работать. В то время как левая представляет значительно более зыбкие понятия, следование которым, к тому же, во многом противоречит урокам менеджмента. И в результате в условиях ограниченных ресурсов и сроков менеджеры реально выделяли ресурсы на документацию и работу с условиями контракта, а не на решение вопросов работоспособности софта или совместному с заказчиком решению проблем. А опыт IT-проектов однозначно говорит, что если делать акцент на вторую часть ценностей в ущерб первой, то проект точно не будет успешен. Понятно, что когда качаешь маятник, то он качается гораздо дальше, чем хотелось бы. С ценностями Agile-манифеста это тоже произошло, в некоторых командах начали вести проект без документации и процессов вообще, не работать с условиями контракта и откликаться на любые изменения мгновенно так, что к ходу проекта вполне возможным было применить поговорку «нас невозможно сбить с пути — нам все равно, куда идти». И потому в современных условиях обязательно надо помнить о ценности обоих частей, но не забывать о сравнительной важности, которую задает манифест, она по-прежнему актуальна. Но ценности остаются пустыми декларациями, если организация работы не позволяет их достигнуть. И потому помимо ценностей Agile-манифест включает принципы организации работы. Важно, что принципы не следуют из ценностей, они опираются на обобщенный опыт ведения IT-проектов, и несут довольно много специфике отрасли. С этим связана сложность при переносе Agile-методов в другие отрасли: ценности перенести относительно просто, в их основе лежит результативность и сотрудничество, которые носят общезначимый характер. И я видел адаптации ценностей Agile-манифеста для продаж, маркетинга, образования и ряда других отраслей. А вот принципы, по которым следует организовывать работу для достижения успеха, могут значительно отличаться из-за специфики отрасли. Именно из-за отраслевой специфики я не разбираю принципы подробно: IT-шники их и так знают, а остальных надо будет излишне погружать в контекст отрасли, обосновывая их.

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

И, наконец, самая известная часть Agile — конкретные методы организации работы, такие как Scrum. Они дают способ воплощения принципов в виде некоторых процессов. Они обладают простотой и наглядностью, и потому привлекательны. Казалось бы, ничего сложного: берешь руководство и воплощаешь в организацию компании. Однако, будучи конкретной реализацией принципов, они обладают ограничениями, касающимися класса проектов, для которых они эффективны. Про это часто забывают, пытаясь применить их для совсем других категорий проектов. А еще забывают о том, что применение организационных фреймворков типа Scrum в IT поддержано большим количеством инженерных средств и практик, таких как Continious Integration, автоматические тесты, Task tracker и многих других. Если мы переходим в другую область, то эти средства тоже следует забирать. Одни из них забрать легко, например, Task tracker или доски, Jira сейчас применяется для любых задач, а не только в IT. Другие перенести невозможно, и надо вырабатывать альтернативные способы, чтобы обеспечить организационному фреймворку необходимую поддержку.

Так что простота Agile-методов — кажущаяся. Курсы и тренинги для начинающих обычно показывают ту часть, которая необходима для освоения фреймворка и трансформации организации под руководством опытного Agile-коуча, а не самостоятельно. Для самостоятельной работы надо разбираться в их конструкции глубже. Это и будет предметом следующих статей, начнем мы со Scrum, потом будет Kanban и более сложные конструкции, а дальше рассмотрим варианты применения для решения разных задач и конкретные кейсы Agile-трансформации. Естественно, это теоретическое знание все равно не заменит практического опыта, который есть у Agile-коучей. Но, я думаю, он позволит вам лучше разобраться в спектре Agile-методов и разумно выбирать варианты и стать квалифицированным заказчиком внедрения Agile. Тем более, что универсальных специалистов, знающих и способных внедрять все Agile-методы, практически не существует, а значит необходимо выбирать того, кто владеет методами, подходящими для вашей организации. Особенности вашего бизнеса знаете вы и потому конкретные решения принимать вам самому или совместно с ним. Вариант трансформации по готовому решению тут не работает.

Так же мы будем рассматривать Scrum — метод организации работы команды, который определил успех Agile-подхода. Да, он — не единственный, не самый первый, и далеко не самый общий, но именно его эффективность привела к широкому распространению Agile. Одна из причин — оказалось, что за счет разделения ответственности менеджера и командной работы в Scrum удается преодолеть дефицит компетентных руководителей групп и компетентных разработчиков. С появлением персоналок, доступных мелким и средним компаниям, и вызвавший большую потребность в IT-проектах этот дефицит был очень острым и именно он, на мой взгляд, способствовал быстрому распространению Agile-подходов на Западе. На постсоветском пространстве появление персоналок совпало с развалом оборонки и в IT пришло очень много квалифицированных инженеров, поэтому потребность была не столь острой. Следы этого сохранились и сейчас, но в целом современная IT-разработка основана на Agile-методах и на Западе и в России. Более того, если кто помнит главу о развитии IT-менеджмента в целом, с тех пор произошел еще один сдвиг культуры, о котором мы тоже будем говорить. Еще один фактор состоит в том, что в Scrum вставлены специальные предохранители против возврата к обычному менеджменту, и потому он способствует пониманию командой ценностей и принципов Agile. Но по этой причине его внедрение — всегда революция. В отличие от Kanban, который имеет гораздо более широкий диапазон применения. Он внедряется эволюционно, и его удерживает культура, а не процессы, а это всегда сложнее. Kanban мы тоже рассмотрим, как и выбор конкретных методов в разных ситуациях Agile-трансформации.

Scrum — пять изменения организации команды, принесшие успех Agile

Мы начинаем рассматривать Scrum — метод, которому Agile обязан своим успехом. И начну я это со списка пяти принципиальных изменений организации команды, которые он принес, а затем буду рассматривать их подробно.

— Кроссфункциональная команда вместо функциональных отделов

— Разделение ответственности менеджера на три части: Product Owner, Команда и Scrum Master

— Закрепление в процессе управления через самоорганизацию команды с предохранителями против микроменеджмента

— Визуализация продвижения к результату с помощью доски и burndown chart

— Короткий цикл поставки ценности с обратной связью — это обеспечивает результативность

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

Надо отдельно остановиться на том, что такое «кроссфункциональная команда», каких специалистов в нее надо включать? Общий ответ звучит так: всех, чьи действия существенных для комплексного решения задач, возлагаемых на команду. Команда может зависеть от внешних специалистов только в тех работах, которые нормированы и предсказуемы, и службы выполнения которых представляют инфраструктуру, то есть не являются ограничением для потока задач команды. В IT хорошим примером являются специалисты баз данных. Обычно разработчики имеют ограниченные компетенции по работе с базами данных и в команде специалист высокого уровня не нужен. Однако, когда идет разработка высоконагруженного приложения, для которой технические решения по работе с базой данных существенно влияют на его работоспособность, такой специалист в команде необходим. Аналогично и вне IT. Например, если решение задач включает заключение договоров, при этом договора — типовые, а юристы и бухгалтерия имеют налаженный документооборот, обеспечивающие прохождение договора в удовлетворительном темпе, то они могут быть за пределами команды. А вот если команда занимается уникальными сделками, требующими привлечения юристов и бухгалтеров для грамотного оформления, включая, возможно, переговоры с клиентом, то они должны быть в команде.

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

Просто в IT это началось лет на 10—15 раньше, чем в остальных отраслях и не называлось таким образом.

Второе изменение организации — разделение ответственности менеджера, на мой взгляд, является ключевым. Его часто не акцентируют, а просто сообщают, что согласно Scrum Guide, команда включает в себя Владельца продукта (Product Owner), членов команды разработки (Development Team) и Скрам-мастера (Scrum Master). Product Owner отвечает за продукт, то есть за содержание той ценности, которую команда создает, команда разработки создает эту ценность, а фокус Скрам-мастера — помощь команде в ее самоорганизации для того, чтобы поставлять эту ценность быстро и качественно. Такое разделение решило старый спор о том, кто лучший руководитель в инженерных проектах — специалист в предметной области, или универсальный менеджер, который в предметной области не разбирается, зато обладает нужными soft skill, которые отсутствуют у предметника.

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

В целом ответственность за технические решения по реализации лежит на команде. Scrum не говорит, как именно она устроена, однако он явно выделяет мероприятия, на которых реализация должна быть прояснена достаточно для уверенной оценки ее трудоемкости. И детали отдает на самоорганизацию команды. При этом, если компания устроена так, что в командах много новичков с недостаточным опытом, то часто выделяется роль технического лидера (Tech Lead) или архитектора — опытного специалиста, отвечающего за технические решения. Но это должно быть обосновано, и не случайно это не проявлено в Scrum Guide: если команда включает опытных самостоятельных разработчиков, то выделение ответственного за технические решения наоборот. является вредным и демотивирует других членов команды, превращая их в исполнителей. Поэтому лучшая практика — когда технические решения готовит исполнитель, а по существенным вопросам предлагает их членам команды на review. Отдельно надо подчеркнуть, что основная ответственность за организацию работ лежит на команде, а не на Scrum Master, который лишь помогает команде соорганизоваться. И это третье изменение — управление через самоорганизацию, блокировка микроменеджмента. Во всех учебниках по менеджменту говорят, что микроменеджмент не эффективен, что руководитель должен организовать работу так, чтобы не быть поглощенным операционной системой, ежедневно раздачей задач. А в Scrum это просто сделали на уровне процесса — в нем нет места, где можно отдать указания. Вообще. И если у члена команды с решением задачи возникают трудности — то он тоже не идет к кому-либо за указаниями, а запрашивает помощь по своему выбору, не отдавая при этом ответственность. А чтобы он не забыл и не стеснялся это делать, в процедуру ежедневных встреч (Daily Scrum Meeting) включен вопрос — что мешает продвигаться к решению задач.

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

Отметим, что предохранители против микроменеджмента внутри процесса не будут работать, если окружение этому не способствует. Системы мотивации и оценки должны быть адекватны такой организации, а не противоречить ей. И в целом ценность самоорганизации должна быть признана руководством и командой, без нее в Scrum нет смысла. Раз мы разделили ответственность, возникает задача синхронизации представлений всей команды о продвижении проекта. И успех Scrum обусловлен тем, что он предложил простые инструменты для этого — доску и burndown chart, а также необходимое количество встреч для синхронизации. Это — четвертое изменение. Отметим, что одному руководителю такие инструменты не нужны, он вполне может работать диаграммами Ганта или другими сложными средствами, а вот требования для инструментов, используемых всей командой — гораздо выше. Техника работы с досками далее развивалась, и сейчас может дать эффект даже без изменения процессов, внедрение Kanban, например, начинается именно с визуализации на доске потока работ. В следующей статье мы ее обсудим подробнее.

А последнее, пятое изменение — итеративная поставка ценности. Это та самая схема Scrum, которая очень популярна, и с которой обычно начинают рассказ. Но которую часто понимают упрощенно — мы просто квантуем поток. Впрочем, иногда это уместно, потому что Scrum могут использовать как эффективный инструмент перестройки культуры компании, благодаря тому, что в процесс встроены предохранители против старого менеджмента, и Agile-коуч может не просто заметить, а явно и обоснованно указать команде на возврат к старому. Ну а через некоторое время это начинают делать Скрам-мастера и другие члены команды. И их замечания невозможно отвергнуть — есть Scrum Guide, который надо выполнять. Да, можно не выполнять — но тогда надо честно признать, что Scrum у вас — лишь вывеска, а не содержание.

Схема Scrum — сложная, она включает в себя и функциональную схему процесса и реализацию его элементов, и я ее тоже буду разбирать отдельно, уже после статьи про доски. А сейчас надо сказать, что Scrum-процесс — он на уровне команды. И он ничего не говорит, как синхронизовать работу разных команд, организовать управление компанией в целом. Это можно делать с помощью Kanban для потока ценности компании в целом, или использовать другие фреймворки, или строить собственные конструкции.

Доска — визуализация текущего состояния работы

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

Для начала определим, что такое работа? Выполнение любого проекта, да и вообще работа любого подразделения представляет собой выполнение некоторых задач. Задачи могут быть простые, выполняемые одним человеком, или сложные, распадающиеся на подзадачи. Выполнение задачи включает в себя несколько стадий, каждую из которых может выполнять отдельный исполнитель. Одновременно в работе может быть от десятка задач для небольшой команды, до нескольких сотен для большого подразделения. И все это надо наглядно представить. Все это достаточно хорошо проработано в классическом менеджменте, и тут нет ничего нового.

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