Хватит приседать перед бизнесом
ИТ-специалисты довольно долго приседали перед бизнесом в глубоком реверансе, обосновывая каждый шаг на пути компаний к автоматизации. Но сейчас со сменой термина на цифровизацию стоит задуматься об изменении основной точки приложения сил и заниматься не столько концептуальными и консалтинговыми проектами, сколько практической организацией разработки, внедрения и эксплуатации ИТ. Потому что именно эти задачи не позволяют компаниям получать отдачу от информационных технологий. При этом существует большое количество стандартов, методик, лучших практик, которые описывают, как выстроить управление ИТ наилучшим образом. И тут чем раньше начнешь об этом заботиться, тем лучше. Об эксплуатации информационных систем надо задумываться на самых ранних этапах их проектирования и построения. То, какими будут сервисы, предоставляемые ИС, необходимо учитывать при проектировании их архитектуры и выборе технологий.
На заре автоматизации основной задачей внедренцев было убедить руководство организаций, или, как их называли, представителей бизнеса, в ее необходимости. Самым простым казалось посчитать эффективность, под которой обычно понимали только экономическую составляющую. Напомню, что в советское время в период централизованного государственного финансирования проекта создания и внедрения информационных систем требовалось финансовое обоснование, без которого средства на ведение проекта просто не предоставляли. К слову сказать, проект должен был также вестись в соответствии с ГОСТами (34, 24, 19). Если чего-то не хватало, проект просто не начинался или немедленно прекращался. Так что обосновывать затраты разработчики умели, их этому учили в институтах и на работе.
Таким образом, в ИТ прочно поселился термин «возврат инвестиций», или ROI, в наличии также присутствовали специалисты, умеющие его рассчитать, а убеждение или отрицание пользы автоматизации со стороны руководителей в большей степени зависело от мастерства продавца.
Однако, думаю, это уже давно ни для кого ни секрет, что мерить какую-либо деятельность только финансовыми результатами, совершенно неправильно. Эта информация определяет только текущий срез одного из направлений работы организации, ориентирована на прошлые успехи и односторонне отражает будущие возможности, и таким образом совершенно не показывает реальную картину. Именно поэтому еще в середине прошлого века появились такие технологии, как BSC (Balanced Score Card) Нортона и Каплана, которые пытались на основании системы показателей представить более объективную ситуацию работы организации. Упомяну, что есть несколько вариантов BSC, специально ориентированных на оценку ИТ. Есть также модели эффективности ИТ, разработанные в разных странах мира для оценки ИТ государственных организаций. В начале века такая модель была разработана и в России. Конечно, ни одна из этих моделей не ограничивается только ROI или NPV (Net Present Value).
Поскольку мне многократно приходилось считать ROI, смею утверждать, что сделать это практически для любого проекта ИТ не представляет особой сложности. Намного труднее выяснить после окончания проекта, действительно ли инвестиции окупились. Вспоминаю случай, когда по настоятельной просьбе ИТ-директора крупного банка мы рассчитали ROI внедрения системы управления инцидентами и конфигурациями, в результате расчета система должна была окупиться за 9 месяцев. Однако этот расчет так и не попал на стол председателя правления банка, который подписывал договор. В последний момент ИТ-директор убрал его из приложений к договору. Он объяснил, что опасается, как бы председатель правления не вызвал его через 9 месяцев и не потребовал показать, что инвестиции действительно окупились. Это действительно непросто сделать для многих проектов по нескольким причинам, основными из которых являются:
- Посчитать, сколько на тот или иной процесс тратилось до автоматизации, чаще всего невозможно.
- Вычленить вклад ИТ в выручку и прибыль организации весьма непросто.
- Этот вклад (так же, как и затраты) растягивается на весь период функционирования ИС, то есть считать финансовые показатели надо только после вывода ее из эксплуатации, когда она уже не представляет интереса для руководства. Хотя я ни разу не видела, чтобы этим кто-то занимался.
Итак, многие годы ИТ-специалистов учили, что разговаривать с бизнесом надо не как с равным партнером, а как с лицом, принимающим решения (ЛПР), как убеждать его в необходимости автоматизации, как считать экономическую эффективность ИТ-систем. ИТ-директорам, да и аналитикам с консультантами довольно долго объясняли, что они должны служить переводчиками с «птичьего» языка ИТ на язык бизнеса и наоборот.
Но ситуация давно поменялась. Когда я еще лет 10 назад спросила владельца компании среднего размера, считали ли они при внедрении ИС логистики эффективность, он мне ответил: «Зачем считать? Мы без этого просто не выживем».
Мне видится граница между автоматизацией и цифровизацией именно в изменении подхода к ИТ: от инициативы ИТ, убеждающих бизнес в необходимости автоматизации, к инициативе бизнеса, который понимает, что без ИТ не выжить. Во втором случае точка приложения усилий ИТ-специалистов смещается от концептуальных вопросов к практическим. То есть не убеждать в преимуществах цифровизации, а как сделать так, чтобы ИТ работали в соответствии с потребностями компаний и не разочаровывали ЛПР.
Однако система образования как довольно консервативная структура поворачивается к практическим вопросам очень медленно. Жизненный цикл ИС часто рассматривается как период от возникновения замысла до сдачи ИС в промышленную эксплуатацию. По аналогии с человеком, жизнь заканчивается в момент рождения. Такой подход особенно удивителен с развитием (пусть не без сложностей) гибких методик и DevOps.
Стратегия — политика — регламент
Другая проблема заключается в увлечении общими словами в ущерб практическим вопросам. Возможно, причина кроется в массовом использовании студентами Интернета и искусственного интеллекта. И там, и там очень много общей информации маркетингового характера, которая в большей степени относится к концепциям и консалтингу, чем к эксплуатации и поддержке. Что приносит больше дохода, о том больше пишут. Отвратить студентов от Интернета и ИИ невозможно, но хотелось бы сформировать у них более критическое отношение к свободным источникам. Однако это весьма непросто, и мне регулярно приходится разъяснять, что экзамены и зачеты студенты сдают мне, а не Интернету или ИИ. И тот факт, что что-то опубликовано и найдено поисковиком, не является доказательством истинности.
В рамках курса «Управление ЖЦ ИС» студенты в командах создают регламенты ряда процессов, таких как «Управление инцидентами», «Управление проблемами», «Управление конфигурациями», «Управление изменениями» и других.
Однако большинство команд все время норовят выскочить за пределы регламентов и создать либо политику, либо даже стратегию. И дело не только в названии, хотя «как вы лодку назовете, так она и поплывет».
Проблема в том, что им легче написать (чаще всего списать из Интернета или получить от ИИ) общие фразы, чем подумать, как это будет работать. Смею утверждать, что чем выше уровень управления, тем больше материалов по нему можно найти в Интернете. А для того чтобы такие статьи подходили разным компаниям, там используется множество общих, ни к чему не обязывающих слов. Приходится каждый раз спускать студентов с небес на землю и разъяснять, что стратегия определяет, куда идти, политика дает принципы, как идти, а регламент описывает, как действовать в том или ином случае. Можно пойти сверху вниз, и это правильно, но дойти до конкретного регламента необходимо.
Потому что именно в практической деятельности проверяются политики и стратегии. Без этого они остаются лучше или хуже написанными документами, увы, не имеющими практического значения.
И пугает, что студентам проще говорить общими фразами, чем подумать, как конкретно будет работать ИС, как надо действовать, когда она перестает работать, как организовать службу поддержки и службу эксплуатации.
Простые вопросы, как поступать в том или ином случае, чаще всего ставят их в тупик. И даже Интернет не всегда помогает.
Важно предусмотреть более практическую направленность студентов в области ИТ. Меньше стратегий, больше практических случаев, в которых надо искать решение. Это можно реализовать, в частности, с помощью различных ситуационных игр. Но что-то пока не видно массового запроса с одной стороны и интереса к их созданию — с другой.
Зарегламентированность
Однако пытаясь четко описать ту или иную деятельность, студенты впадают в другой грех — зарегламентированность. Причину всех ошибок они видят в том, что в регламенте не была учтена та или иная ситуация. Попытка апеллировать к Манифесту гибкой разработки ПО, к тому, что невозможно учесть все возможные ситуации использования ИС ни в требованиях, ни в регламентах и инструкциях, вызывает полное непонимание.
«Значит требования были плохо определены!» — вот что обычно слышишь от них. И даже примеры конкретных проектов не помогают бороться с маниакальной убежденностью в силе предвидения. Было бы легче, если каждый студент обладал таким даром, но вряд ли этого можно от них требовать.
Кроме того, им трудно дается учет эффекта времени, понимание того, что все изменяется, что то, что еще вчера работало, сегодня может работать плохо. Такая «стабильность» приносит свои отрицательные результаты. Например, неоднократно убеждалась, как руководители проектов с невероятной настойчивостью повторяют приемы, которые были успешны в одном проекте, в другом, где они далеко не так успешны.
В рамках курса студенты работают в командах по скраму. В скраме, с моей точки зрения, очень важна, я бы сказала в философском смысле, ретроспектива. Это встреча членов команды, в которой определяется, как велась работа в спринте, что было хорошо, а что было плохо и что можно улучшить. Из года в год студенты пытаются рассказать в ретроспективе, с какими техническими трудностями они столкнулись и что сделать не успели. Некоторые команды удается настроить на правильный лад, но другие упорствуют.
Ретроспектива является конкретным практическим методом применения цикла PDCA (Plan-Do-Check-Act) Деминга — Шухарта. А именно реализацией идеи о том, что любой процесс, как бы хорошо он ни был организован изначально, обязательно начнет с течением времени ухудшаться, если ничего не предпринимать. Как говорила Алиса Льюиса Кэрролла, «чтобы стоять на месте, нужно бежать, а вот чтобы двигаться вперед, нужно бежать в два раза быстрее». Так что процессы нельзя оставлять без присмотра. И такой подход, который можно банально сформулировать как «не останавливайся на достигнутом», применим к любой деятельности.
Интересно, что одна из команд невольно обозвала ретроспективу ретроперспективой, что, возможно, даже лучше ей подходит.
В ретроспективе некоторые команды с завидным упорством повторяют: в следующем спринте надо лучше распределять задания. И приходится им напоминать, что раздача заданий противоречит самому принципу гибкой разработки. В частности, противоречит канбану.
Канбан как основа нового социально-экономического строя
Канбан, конечно, исторически возник как приложение к гибким методикам разработки ПО, хотя довольно давно стал важным элементом различных гибких методик, в частности, скрама. Канбан, зародившись в «Тойоте», то есть в автомобильной промышленности, может использоваться практически в любой коллективной деятельности.
Суть его состоит в том, что работник сам выбирает из списка дел, чем ему заниматься и, соответственно, несет ответственность за свой выбор и выполнение выбранной задачи. При этом технически все происходит открыто, изначально с помощью простой доски, разделенной по вертикали на этапы работы, и стикеров с задачами. Конечно, сегодня доску используют редко, а применяют соответствующее ПО.
Правда, в головах студентов такой демократический подход иногда не укладывается. Хочется некоторым из них кем-то поруководить, наверное.
Вот эта свобода специалиста в выборе деятельности, несомненно, придает канбану совершенно особенную роль в развития общества и человеческих отношений. Ведь трудно представить себе раба, или крепостного крестьянина, или даже рабочего на конвейере, который выбирает, что ему делать.
Четко иерархическая система, которая отдает всю власть в руки одного человека, дирижера, плохо работает в гибких и очень гибких системах.
Метод хореографии, основанный на хорошем взаимодействии, прозрачности, понимании своей роли, своей ответственности и самостоятельности «танцоров» лучше подходит для нашего времени. И современные специалисты работают совершенно по-другому, когда чувствуют, что им доверяют.
Заключение
Чему же можно и нужно учить студентов? Главное — думать! Не полагаться на авторитеты, тем более на Интернет и ИИ. Учитывать текущую ситуацию и состояние окружающей среды и пытаться прогнозировать будущее, быть гибкими и избегать общих фраз. Больше внимания уделять практике и проигрыванию различных ситуаций. Объяснять, что нет возможностей без рисков, и наоборот. Что выгоды всегда связаны с затратами («без труда не вытянешь и рыбку из пруда»). Что каждый работник, даже на самой небольшой должности, может и должен делать вклад в общее дело, а не бежать как собака Павлова за морковкой зарплаты. А то превратишься обратно в обезьяну, а морковки у работодателя закончатся.
Опубликовано 04.02.2026
