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

Развитие и провал регулярного менеджмента в 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-трансформации.