Деятельность предприятия, связанная с освоением новых информационных технологий, похожа на неистощимый ручеёк проектов (которые project). Захотели автоматизировать продажи или производство — запускается проект. Решили наладить внутренний сервис — ещё один. А уж если начали выводить на рынок высокотехнологичный продукт, то ручеёк стремительно выходит из берегов.
Работа с проектами традиционно считается самой сложной и ответственной в ИТ-отделе. Показатели «успешного выполнения проектов» особенно выделяют при расчёте премий. Неудивительно, что ИТ-директор готов прилагать значительные усилия к тому, чтобы его проектная деятельность была устроена наилучшим образом.
Изобретать велосипед при этом вроде как не приходится, потому что всему необходимому обещает научить дисциплина «Проектный менеджмент» (project management), уже почти отлитая в стандарте ISO:21500.
Судя по темпам роста своей популярности, эта дисциплина уже совсем скоро войдёт в программу детского сада. Кажется, что даже у клининг-менеджеров появились свои уставы проектов, календарно-сетевые графики и статус-отчёты. Потому-то сегодня в ответ на предложение «поговорить со стейкхолдерами о профилях рисков в разных сценариях сжатия расписания» уже никто не обвинит вас в поклонении Ктулху.
Когда речь заходит о выборе хорошего учебника, на язык сразу просится слово «PMBOK». Возможно, фанаты команды из туманного Альбиона вспомнят о «PRINCE2», а поклонники восходящего Ярилы предпочтут «P2M». Но в России, стараниями института PMI и им сочувствующих, именно PMBOK стал настольной Библией для большинства менеджеров.
Выходит, достаточно освоить хороший учебник, и успех обеспечен?
Да… но нет.
Некорректна сама постановка вопроса.
Сложность кроется в нюансах понятий «успешного» и «полезного» проекта. Далеко не каждый успешный проект становится действительно полезным для предприятия, да и не каждый полезный проект можно считать успешным по формальным признакам.
Чтобы разобраться, почему так получается, придётся погрузиться в детали.
Занимательная статистика
Понятие «успешного» проекта пришло из дисциплины «Проектный менеджмент». Оно означает, что в ходе проекта удалось освоить выделенный бюджет в установленный срок и выдать запланированный продукт, удовлетворивший стейкхолдеров.
Перечисленные метрики очень легко отслеживать и предъявлять, поэтому они часто используются для премирования и исследуются в статистических опросах. При этом считается, что строгое следование дисциплине, продвигающей эти метрики, помогает сделать проект «успешным».
Данные опроса PMI «Pulse of the Profession» (2018) подтверждают эту мысль. Раздельные показатели по «аутсайдерам» и «чемпионам» демонстрируют несомненную связь между уверенным владением дисциплиной и достижением «успеха». Результат ожидаемый, ведь практики управления проектами заточены именно под эти показатели.
В среднем, формальные процедуры управления проектами в том или ином виде имеются у 93% опрошенных, при этом 69% выполненных ими проектов считаются «успешными». Это очень хороший показатель, учитывая, что часть опрошенных занимается проектным управлением лишь от случая к случаю.
Но верна ли эта статистика в отношении ИТ-проектов? Что если именно к ним относится большинство неудачных исходов? Например, те же данные утверждают, что более половины проектов сталкивается с проблемами неконтролируемого изменения границ и расползания требований. Знакомые симптомы, не так ли?
Наверняка в проектном аду есть свой особый ИТ-отдел, в котором бесконечные «добавим кнопочку сюда» и «прикрутим бантик здесь» ближе к финалу превращаются в «это совсем не то, что требовалось, срочно всё переделываем». Некоторые даже считают, что для ИТ-проектов это нормально, и почему-то называют такой цирк «работой по Agile».
Спешу успокоить, статистика по ИТ-проектам отличается лишь незначительно.
Вслед за популярным исследованием «The Standish Group», многие повторяют, что «только 30% ИТ-проектов заканчиваются успешно». При этом они забывают добавить, что «ещё 50% ИТ-проектов тоже заканчиваются, хотя и со средними результатами».
Достаточно заглянуть в публичный отчёт «CHAOS Report» (2015), чтобы в этом убедиться. И хотя данные в нём уже не первой свежести, стабильность показателей из года в год вполне успокаивает.
Кстати, листая страницы этого отчёта, можно вынести одно полезное наблюдение. Оно не тянет на открытие, но даёт представление о шансах на успех при разных раскладах.
Оказывается, маленькие проекты, внедряющие готовый софт с небольшими доработками по технологиям Agile, имеют в 50 раз больше шансов на успех, чем гигантские начинания, разрабатывающие уникальный софт по классике Waterfall.
К таким же выводам пришла Фирма 1С в докладе «1000 проектов внедрения 1С:ERP» (2016). Выяснилось, что большинство «крупных» внедрений коробочной «1С:ERP» обходится лишь небольшими доработками. При этом они укладываются в плановый срок в 49% случаев, и в бюджет в 80% случаев, что в целом вполне приемлемо.
Статистики по «успешным» проектам Фирма 1С не приводит. Однако, судя по динамике показателей предыдущих лет, их доля составляет около 30% и повторяет данные «CHAOS Report» по выборке «крупных» и «сложных» проектов.
В целом, ситуация по ИТ-проектам соответствует наблюдениям PMI, а значит и вывод о необходимости следовать проектной дисциплине остаётся верным.
Очень важно делать проекты правильно, по учебникам. По возможности — разделять крупные и сложные проекты на этапы, использовать готовые решения и гибкие технологии.
Проще говоря, «успех» ждёт тех, кто выполняет проекты правильно.
Освежающая реальность
Понятие «полезного» проекта устроено сложнее и заставляет подумать уже не о работах, а о преследуемой ими цели. Близкой родственнице той самой «Цели», о которой писал Элияху Голдратт, потому что «полезная» цель должна формулироваться точно так же — на уровне предприятия в целом.
Верный признак будущих неприятностей на проекте — это цель, повторяющая содержание, например: «автоматизировать такой-то процесс» или «внедрить такую-то программу». Если заказчик не забьёт тревогу вовремя, то процесс будет «автоматизирован», а программа «внедрена», однако пользы в результате ждать не стоит.
Вот один показательный случай из моей практики.
Небольшая мебельная фабрика. Очень хочет перевести производство на новенькую «1С:ERP». Потому что как раз завелись лишние деньги, а старая софтинка стала совсем уж плохой.
Ну, думаю, похоже на классику. Фабрика маленькая, процессы не поставлены, учёт на коленке. Новая ERP-система точно пригодится.
Пошли смотреть производство… а там Канбан. Настоящий. Запуск работ по вытягивающим заказам, карточки на всех изделиях, доски и контейнеры для ограничения загрузки в цехах. И главное — старая софтинка бодро крутится: мониторит поток продукции, отслеживает выполнение заказов и оперативно рассчитывает их себестоимость. Всё работает как часы.
Осторожно интересуюсь, а зачем понадобилась «1С:ERP»? Что именно не устраивает, какие есть проблемы? Может быть, какие-то сбои в потоке работ, возросла нагрузка и старая система уже не справляется?
Оказалось, что в целом всё хорошо. Небольшие проблемы есть по логистике и сервису, потому что туда Канбан ещё не добрался. Просто почему-то идея замены старой системы именно на производстве показалась стоящей.
В общем, оставили производство в покое и ушли к логистам.
Можно ли было выполнить «успешно» исходный проект? Несомненно.
При наличии грамотных специалистов и профессиональных менеджеров, бюджет был бы ловко освоен, сроки виртуозно выдержаны, а все задачи героически решены.
Но принёс бы он пользу для предприятия в целом? Скорее всего, нет.
Замена одной программы на другую не решит проблем, если этих проблем нет. Зато наверняка создаст новые, причём в самых неожиданных местах.
Поэтому до погружения в проект стоит осмотреться снаружи. Проверить — актуальна ли проблема, которую предстоит решить, и принесёт ли её решение максимальную пользу всему предприятию? Или имеет смысл переключиться на что-то более насущное?
А вот другой случай, который только выглядит похожим.
Большой сыроваренный завод. Тоже хочет поставить новую «1С:ERP», хотя неплохо обходится и её предшественницей. Лишних денег совсем нет, зато очень нужны какие-то новые фишки, упомянутые в рекламных буклетах.
Ну, думаю, и такое бывает. Ведь явно что-то умеет новая ERP-система, что старой только снится. Осталось понять — что из этого срочно понадобилось.
Идём смотреть производство, а там абсолютная автоматизация. По одной трубе молоко поступает в цеха, а из другой выходят готовые кругляши сыра. Всё роботизировано, всё блестит и сверкает металлом, и вокруг — ни души. Полный восторг, только непонятно что здесь ещё можно усовершенствовать.
Подвох ждал на выходе из варочных цехов. Суровый рабочий в каске грузил эти кругляши на тележки и с грохотом увозил их в цеха упаковки и созревания. Там тянулись бесконечные тёмные коридоры, обрывающиеся в циклопических размеров камерах. Затаившиеся в недрах этого лабиринта грузные стальные короба злобно гудели, поддерживая точно выверенную температуру и влажность. Повсюду толпились и сновали люди, а вместо компьютеров сидели строгие учётчицы с шариковыми ручками и лохматыми тетрадями.
Убедившись, что на тёмной половине завода действительно пригодится ERP-система, да ещё и с модулем MES, возвращаемся к разговору с руководством. Но выясняется, что неказистые цеха отлично работают, несмотря на лохматые тетради. А текущая задача — собрать постатейную себестоимость каждой головки сыра, чтобы можно было разбираться с приоритетами для развития.
Понятное дело, затратный переход на «1С:ERP» отложили до лучших времён, а вопрос с себестоимостью снесли на небольшие доработки имеющегося софта.
Исходная задача была поставлена грамотно. Но вот её решение слишком уж походило на применение тактического ядерного оружия по воробьям.
Люди постоянно забывают о том, что одну задачу можно решить множеством способов. Каждый способ имеет свою цену и свои ограничения. При этом нельзя сказать заранее, какое решение окажется лучшим в конкретной ситуации.
Поэтому до начала проекта также важно оценить его изнутри. Просчитать — какие плюсы и минусы есть у выбранного решения, а также ещё раз взвесить все доступные альтернативы. Аккуратные расчёты на этом этапе радикально повышают отношение пользы к затраченным силам и времени.
Вывод напрашивается сам собой.
Важно выбирать правильные проекты, польза от которых очевидна. Придётся просчитывать — какие выгоды несёт проект на уровне предприятия (взгляд наружу), и как решить его задачу проще и быстрее, чтобы затраты не сожрали весь эффект (взгляд внутрь).
Округляя мысль, «пользу» приносят только правильные проекты.
Настоящая тайна
Вот так и получается известный коан — делай правильные проекты правильно!
Конечно, помощи от него в таком виде немного. Он позволяет помнить о важном, но не даёт инструкций что именно нужно делать. Это нормально, ведь большинство проектов слишком сложны, чтобы уместиться даже в сотне коанов. Хотя и говорил ещё старик Эйнштейн, что сложные вещи можно и нужно объяснять простыми словами, но не стоит ждать мгновенного сатори и постижения всех тонкостей после таких объяснений.
Зато становится ясно почему одного лишь проектного менеджмента недостаточно для успеха. Правильное управление работами ничего не добавляет к правильному содержанию этих работ. За решение содержательных вопросов на проектах отвечают инженеры. И если для небольших задач, помещающихся в одной голове, иногда хватает компетенций опытного специалиста, то уже крупные проекты приходится штурмовать коллективно.
Для коллективной борьбы со сложными конструкциями предназначен «Системный подход», который позволяет разбираться с системой (system) последовательно, по частям, но при этом удерживать её в общем сознании как единое целое, и не терять важных взаимосвязей.
Современная версия этого подхода лежит в основе дисциплины «Системная инженерия» (systems engineering). Это значит, что от глубокомысленных коанов можно перейти к конкретным рекомендациям и стандартам.
Далеко ходить не придётся, так как порядок действий в этом вопросе железный. Начинать нужно с фундаментального учебника «Системное мышление 2019» Анатолия Левенчука. Сразу настраивайтесь на то, что перечитать его придётся раз семь. Зато после этого вам откроются запретные манускрипты ISO:12207, ISO:15288 и ISO:42010, труды алхимиков из BKCASE и INCOSE, и другие передовые своды инженерных знаний.
Пока же очень хочется прихватить только одну концепцию.
Причём заранее понятно, что сжатый пересказ основ системной инженерии, равно как и попытка насвистеть «девятую симфонию» — занятие несерьёзное. Но алгоритм системного рассмотрения проектной деятельности настолько хорошо подводит итог под сказанным выше, что рискнуть стоит.
Системный подход к инженерному проекту выглядит так:
1. Выявите и согласуйте потребности стейкхолдеров в надсистеме (снаружи)
2. Определите требования и выберите архитектуру целевой системы (изнутри)
3. Только после этого приступайте к организации работ по проекту
4. …
5. PROFIT придётся повторить рекурсивно для каждой подсистемы
Понять всё это без чтения учебника совершенно невозможно, поэтому просто посмотрим как полученная выше максима раскладывается по этой схеме.
1. Проблема, которую решает ИТ-проект, очень сложно устроена снаружи. Разберитесь с ней в первую очередь, до начала работ.
Ни один ИТ-проект не живёт в вакууме и не приносит пользы сам по себе. Он живёт в контексте предприятия и служит для реализации задуманных в нём организационных изменений. Вот почему до стадии задумки проекта должна быть проделана большая работа по выявлению текущих возможностей развития, их ранжированию и оценке. Результаты этой работы обычно оформляются в виде стратегии организационного развития, затем прорабатываются в архитектуре предприятия и только после этого спускаются на уровень ИТ-архитектуры, на котором возникают задачи ИТ-проектов.
2. Решение, которое предлагает ИТ-проект, очень сложно устроено изнутри. Продумайте его в разных вариантах, также до начала работ.
Сложность внешнего контекста задачи ИТ-проекта умножается на внутреннюю сложность и вариативность устройства самих информационных решений. Часто эти решения состоят из массы разнородных, плохо совместимых и независимо действующих модулей, завязанных на такой же пёстрый и весьма глубокий технологический стек. Учитывая, что при реализации изменений в ИТ-ландшафте сохраняется необходимость поддерживать приемлемый уровень текущих сервисов, вся работа начинает походить на операцию по замене двигателей у летящего авиалайнера.
3. Как следствие, сам ИТ-проект должен быть устроен не менее сложно. Предусмотрите все работы, необходимые для всех частей системы.
Никакая часть будущей информационной системы не встанет на место сама, поэтому для каждой должны быть предусмотрены свои работы в проекте. Для выполнения необходимых работ в арсенале системной инженерии имеется много общих и предметных дисциплин: бизнес-анализ, инженерия бизнеса, инженерия предприятия, инженерия организационных процессов, инженерия данных, программная инженерия и многие другие. А для управления всем этим богатством придётся подключить полноценный организационный проектный менеджмент: на корпоративном, стратегическом, портфельном и программном уровне.
Стало понятнее? Значит, PROFIT.
Если понятнее не стало, это тоже нормально. Потому что очень редко вся эта сложность кем-то осознаётся и контролируется в реальной жизни. Зато отчётливо видно почему ИТ-проекты так же редко могут похвастать хорошей постановкой задачи и многократно меняют границы в ходе работы.
Что же с этим делать? Терпеть и страдать?
Никоим образом! Осталось упомянуть про современные методологические дисциплины, помогающие соединить все эти теоретические подходы в единую практическую методику. Достаточно полную, чтобы справляться с самыми разными корпоративными задачами, но при этом достаточно понятную, чтобы не требовать от исполнителей степени доктора наук.
Вот она, настоящая тайна:
Для того, чтобы ИТ-проекты на предприятии выполнялись правильно и в правильных местах, нужно собрать в единый метод и применять дисциплины Системной инженерии и Проектного менеджмента вместе.
Например, в современном варианте OMG Essence { ISO:15288 + ISO:21500 }
Разбираться с этой тайной, конечно же, будем системно.
Постепенно, по одному уровню за раз.
Продолжение следует…