Дмитрий Безуглый — инженер-системотехник, бизнес-тренер, консультант по организационному развитию и проектированию. Он давно и плодотворно работает в области повышения квалификации системных аналитиков. Какие компетенции требуются от системных аналитиков сегодня? В какой мере аналитики обладают этими компетенциями? Об этом и пойдет наш разговор.
itWeek: Что вы могли сказать о подготовке и компетенциях системных аналитиков? Происходят ли какие-то изменения в этой области?
Дмитрий Безуглый: Изменения происходят, и довольно заметные. Многие компании, занимающиеся разработкой программного обеспечения, сталкиваются сегодня с необходимостью быстрого развития своих продуктов в условиях острой конкуренции. Рынок задвигался, клиент становится все более требовательным, компании должны переходить от поддержки проданной однажды системы к ее комплексному развитию. И здесь перед многими в полный рост встает проблема: для решения сегодняшних задач компетентности специалистов уже не хватает. Прежде всего — не хватает системных аналитиков. Развитие компетенций в бизнес-системном анализе — вопрос очень непростой. Вузы готовых специалистов нужного уровня не выпускают. Опыт участия в реальных проектах сам по себе не гарантирует, что аналитик доберет нужные умения на практике. Дополнительное образование? Во многих компаниях мы сталкиваемся с тем, что люди, прошедшие одиночные тренинги и онлайн-школы, при тестировании знаний понятийного аппарата показывают очень высокие результаты. Но применения усвоенных ими знаний не происходит. Знания, которые люди получают на тренингах или из книг, часто остаются сувенирными и не переносятся в деятельность.
itWeek: Это ведь касается не любого обучения?
Д. Б.: Простые навыки и понятийный аппарат через тренинги доносятся хорошо и часто могут быть применены на следующий же день. Например, скрипты продаж или типизация клиентов. Но компетенции системных аналитиков нельзя сформировать через обучение отдельных сотрудников отдельным навыкам. Реальные комплексные задачи не укладываются в формат практики двух-трехдневного тренинга. А если кейсы и навыки слишком упрощены, то люди не увязывают их с реальными ситуациями и не могут применить в «боевой» обстановке. Бесполезно учить проектировать корабли на примере закручивания шурупов.
itWeek: А что полезно?
Д. Б.: Опыт показывает, что для развития сложной комплексной компетенции нужен комплексный подход к повышению квалификации и аккуратное «переплетение» производственных и учебных задач. Реальный результат приносят достаточно длительные, порядка года, учебные программы. Они включают в себя диагностику текущего уровня аналитиков и возникающих в их работе проблем. Затем — самоподготовку, интенсивное групповое обучение, домашние задания, сессии по работе с реальными кейсами и общие сессии, направленные на обмен опытом с другими участниками процесса разработки и управления продуктом.
itWeek: Вы говорите о форматах обучения системных аналитиков. А чему их следует обучать?
Д. Б.: Наш опыт диагностики и повышения квалификации показывает: есть как минимум четыре направления, по которым мышление системных аналитиков часто не дотягивает до уровня сегодняшних задач. Все начинается с искусства перевода разношерстных пожеланий, жалоб, затруднений и требований со стороны сотрудников компании-заказчика в собственно профессиональную задачу на разработку программного обеспечения. Или на доработку, на развитие информационной системы. Или на развитие отдельной составляющей информационной системы. Уже на этом, самом начальном этапе работы аналитика требуется реальное, практическое владение понятийным аппаратом системного мышления.
Основа успешности в системном анализе — это определение границ и контекста системы, с которой начинает работать аналитик. Как определить эти границы? Как далеко в своем исследовании нужно зайти, чтобы решить проблему заказчика, не потерять важные нюансы, но при этом не запутаться в сетях взаимоувязанных проблем и не потратить время впустую? Конечно, на этом этапе аналитику важно владеть инструментами системного мышления и теории ограничений — такими как анализ заинтересованных сторон, дерево текущей реальности, диаграмма причинно-следственных cвязей (сasual-loop analysis) и т. д. Такого рода методы создают опору для мышления аналитика. Однако они не отменяют и не заменяют необходимости мыслить. Проведение границ объекта своей работы, определение зоны своей ответственности — это нетривиальная задача. Она не решается освоением алгоритмов или заучиванием инструкций, в каждой ситуации она разная и требует системного мышления.
itWeek: Можно ли сказать, что искусство проведения границы — это главное в работе аналитика?
Д. Б.: Умение работать с границами — это, конечно, одна из базовых компетенций. Это включение в границы своей работы всего необходимого и достаточного, чтобы разрешить ситуацию, выяснить и устранить не только симптомы, но и причины проблем у заказчика.
Один из принципов системного подхода: целое несводимо к сумме частей. Поэтому если мы цепляемся за одну какую-то часть, потом за другую, но не рассматриваем объект своей работы как целое, то получается «хотели как лучше, а получилось как всегда». Кроме того, объект может входить в разные системы, и работа каждой системы в результате изменений в объекте не должна быть нарушена. Важно, чтобы аналитик мыслил системно и в каждом контексте понимал, частью какого целого является конкретный объект и где у этого целого границы.
itWeek: Можете пояснить на примере, каким образом неспособность выделить целостную систему приводит к неудачам в работе?
Д. Б.: В моем личном опыте самым ярким примером бессистемного мышления является случай, когда CIO большой аутсорсинговой компании оптимизировал загрузку ИТ-администраторов, половина из которых была студентами. CIO хотел организовать их работу так, чтобы каждый был занят 100% рабочего времени. Организовал, внедрил очередь задач. Сократил штат с десяти до шести человек. Молодец? Ему даже премию дали. А потом оказалось, что в результате некоторые задачи в пиковые периоды могли ожидать решения три-пять дней. В ожидании
itWeek: Умение выделять целостные системы относительно решаемой задачи — это одна из нескольких необходимых компетенций системного аналитика. Что он должен уметь помимо этого?
Д. Б.: Второй важный и часто упускаемый в работе аналитика аспект — это создание концепции решения, ориентированной на заказчика.
itWeek: Что это такое «решение» в данном контексте?
Д. Б.: Термин «решение» — калька с английского solution. В контексте ИТ этот термин обозначает комплекс изменений в ИТ-системах, которые необходимо сделать для достижения результата. Допустим, есть большая работающая система — все предприятие целиком. Эта система состоит из множества разных подсистем, в том числе — из ИТ-систем. И эти ИТ-системы между собой взаимодействуют. И когда на предприятии возникает проблема — что-то начинает сбоить и не работать, необходим системный анализ. Кто-то должен проанализировать возникшую проблему и предложить решение, solution, то есть комплекс изменений, которые нужно сделать в одной, второй, третьей ИТ-системе.
itWeek: А что означает ориентированность концепции решения на заказчика?
Д. Б.: Работая над решением проблемы, далеко не всякий системный аналитик видит ситуацию глазами заказчика. Если задача уже сформулирована, то можно выбирать в качестве основы решения тот или иной алгоритм, ту или иную технологию. Но если не соотносить их с живой ситуацией, внутри которой находится заказчик, то совершенно невозможно понять, при каких условиях одно или другое решение принесет бизнесу максимальную пользу.
В каждой ситуации аналитику важно видеть решаемую проблему как бы изнутри компании, с которой он работает. Важно уметь вставать на точку зрения будущего пользователя создаваемого инструмента. На точку зрения руководителя этого пользователя. В пределе — на точку зрения бизнес-заказчика. Важно увидеть будущее решение глазами того, кто будет это решение использовать. И ответить на вопрос: какую ценность будет создавать решение?
itWeek: Должен ли системный аналитик научиться рассматривать ситуацию, с которой работает, с точки зрения бизнеса заказчика в целом?
Д. Б.: Понимание бизнеса в целом — это очень высокий уровень компетенции системного аналитика. Для того, чтобы продвинуть аналитика в его профессионализме, часто достаточно бывает научить его расширять свое понимание до минимально необходимого контекста. Чтобы он выделял и понимал надсистему или экосистему, в которой будут использованы получаемые им результаты. Это — дальнейшее развитие навыка выделения границ системы. И это также возможное расширение границ ответственности, которую в состоянии взять на себя аналитик.
В конкретных проектах объект работы системного аналитики, т. е. система, с которой он работает, зависит от уровня его задачи. Соответственно, от полномочий, которыми он обладает. Для бизнес-архитектора границами ответственности будет предприятие целиком. А для начинающего аналитика, проектирующего отчет или форму, границей ответственности будет небольшая ИТ-подсистема. Расширения границ объекта анализа — один из основных векторов профессионального роста аналитика. Помните притчу про храм? «Ты что делаешь? Таскаю кирпичи». Это — первый уровень восприятия ситуации. И это как бы аналог функции для проектируемой аналитиком системы. «А ты что делаешь? Я деньги для семьи зарабатываю». Это — второй уровень, это возможности, которые открываются при использовании функций. Здесь мы еще на один шаг продвинулись ближе к смыслу деятельности. «А ты что делаешь? А я храм строю». Это уже третий уровень: цель выработки решения и конечный эффект от использования возможностей.
В контексте разработки программного обеспечения функция для пользователя, скажем, продавца — создать запись о встрече с потенциальным клиентом. Функция — это просто преобразование того, что поступает на вход — в то, что имеем на выходе. Мы создаем удобный интерфейс для этой функции, для внесения записи.
Какую возможность создает такая функция? Она позволяет управлять эффективностью сделок. Здесь заинтересованным лицом является уже руководитель отдела продаж. А еще более отдаленная цель создания такого решения — повысить эффективность продаж, что в свою очередь определяет конечную ценность для заказчика. Заинтересованное лицо здесь — руководитель компании.
itWeek: А должен ли аналитик, чтобы выделить свой участок ответственности, понимать всю ИТ-составляющую, которая есть в компании? Должен ли он понимать работу всех ИТ-подсистем и связей между ними?
Д. Б.: Досконально всё он понимать не может и не должен. Его задача — столкнувшись с проблемой, собрать минимально необходимый объем контекста, чтобы эту проблему решить. Бывают проблемы базового уровня, которые требуют знания только одной маленькой подсистемы. А бывают проблемы масштаба предприятия. Но тогда уже работает не один аналитик, а целая проектная группа. Задача аналитика — сначала определить ту область, которую надо изучить для решения проблемы. И определить тех экспертов, которых нужно вовлечь в работу как со стороны бизнеса, так и со стороны ИТ. Создание представления обо всей ИТ-составляющей компании — это уже задача различного рода ИТ-архитекторов.
itWeek: Наверное, ориентированность на заказчика, умение видеть проблемы и решения «изнутри» — сильно облегчают взаимодействие аналитика с заказчиками и пользователями будущего решения?
Д. Б.: Конечно! Учиться вставать на точку зрения тех, кто будет использовать решение — это означает также и учиться говорить на языке возможностей и целей создания решения. Аналитик должен перестать говорить на птичьем языке железок, кнопок, программ и функций преобразования чего-то во что-то. Он должен начать говорить на понятном заказчику языке возможностей, которые тот получит от решения.
Возьмем, скажем, выпуск обновления в программном продукте или модуле. Перечень новых функций системы обычно мало что говорит даже опытным пользователям системы. А получить обновление, в котором четко написано, чем мне будет полезно использование новых функций — этому пользователь всегда будет рад.
В практическом плане умение размышлять на языке полезности для заказчика позволяет создавать ценные и востребованные для бизнеса решения. Не проводить слепую автоматизацию, не дублировать в «цифровом исполнении» сложившиеся в компании способы выполнения работ, а предлагать бизнесу новые возможности. Техническое задание отвечает на вопрос «Что мы собираемся сделать?», а концепция решения отвечает на вопрос «Зачем, с какой целью мы собираемся это делать?»
itWeek: Какие еще компетенции необходимо развивать современному аналитику?
Д. Б.: Сегодня системным аналитикам необходимо осваивать продуктовый уровень мышления. В продуктовом подходе к работе с решением учитываются как минимум два контекста, в которые это решение входит. С одной стороны, решение должно работать для конкретного заказчика. А с другой — нужно формировать не просто персонализированное решение, а решение, которое удовлетворит многих заказчиков.
Вот этот второй контур, собственно, продуктовый — связан с необходимостью учитывать коммерческую значимость той или иной решаемой задачи. В большинстве случаев аналитик не выполняет работу руководителя продукта, но понимание этой области ему необходимо.
itWeek: Касается ли конкретного заказчика тот факт, что аналитик держит в уме и других заказчиков?
Д. Б.: Это касается и конкретного заказчика. Важно донести до него обоснованность предлагаемого решения. И показать ему на цифрах: если это индивидуальный пошив и только под вас, то будет стоит столько-то и эти деньги могут не перекрыть тех плюсов, которые вы получите.
Сегодня очень мало компаний в мире могут себе позволить разработку исключительно под себя. Если качественно, то очень дорого! Качественное решение требует большого количества специалистов, технологий. Мы как пользователи привыкли к тому, что действительно хорошее качественное решение стоит дешево. Фейсбук, офисный пакет, операционная система — туда вложены тысячелетия труда программистов, но мы получаем их практически бесплатно. Мы можем купить год использования Microsoft Office по цене меньшей, чем стоит один час работы программиста. Возможность дешево предлагать качественные решения позволяют продукты, затраты на создание которых делятся между многими заказчиками. Только в этом случае продукты можно делать более качественными и с гораздо большим коммерческим эффектом и для исполнителя, и для заказчика.
itWeek: Когда мы понимаем, что создаем решение для двадцати заказчиков, то это уже не затраты на один проект, а наши инвестиции в будущие проекты?
Д. Б.: Или затраты в рамках нескольких параллельно идущих проектов. Да, в этом — суть продуктового подхода. Но это работает даже в рамках одной организации. Скажем, в банке десять тысяч сотрудников, которые работают с одной и той же функциональностью. Мы физически не можем опросить их всех и сформировать согласованное мнение. Даже выбор отдельных экспертов не позволяет действовать аналитику по схеме «пошли, спросили и сделали как нас просят». Спрашивать-то аналитик спрашивает, но ответственность за решение лежит на команде продукта. Задача — сначала найти эффективное общее решение. А потом убедить пользователей, при всем различии их вкусов и предпочтений, что это предложение будет эффективнее и лучше чем то, то они делают сейчас.
itWeek: Продуктовый подход — он ведь и про экономику проекта?
Д. Б.: Да, экономическая сторона решения очень важна. Мы это решение продаем, заказчик нам за него платит. Поэтому продукт, содержащий предложенное решение, должен быть сформирован так, чтобы имелся весь комплекс сервисов, необходимых для его использования. Информирование о создании решения, обучение пользователей, поддержка, назначение цен и все остальное. Если создано только решение, продукт не может быть успешным. Нужно еще учесть, как мы будем это решение поддерживать, как мы будем его предлагать, сколько оно будет стоить и как мы будем его развивать. Если мы неправильно сформировали цену на решение, то мы не заработаем денег на его поддержку и, соответственно, заказчики этого продукта рано или поздно лишатся. А вот когда найден баланс, в рамках которого соразмерены и ценность решения, и то, как мы можем его предложить, продать, а затем поддерживать и развивать — это уже про продукт.
itWeek: Вы рассказали о трех наиболее проблемных наиболее востребованных аспектах мышления системного аналитика. В чем заключается четвертый?
Д. Б.: Четвертая из наиболее важных составляющих касается процессного понимания того, с чем работает системный аналитик. Это умение выделять и видеть процессы, моделировать процессы, мыслить процессами. Умение выявлять, проектировать и перепроектировать те цепочки задач и функций, в результате выполнения которых заказчик получает бизнес-результат. Вот вы спрашивали про понимание бизнеса заказчика целиком. Процессное мышление — это как раз про понимание бизнеса целиком. Для системного аналитика это следующий уровень мышления. Высший пилотаж. И как бы стык компетенций бизнес-аналитика и ИТ-архитектора. Для системного аналитика высокой квалификации важно понимать, как создаваемое им решение участвует в формировании конечной ценности компании заказчика.
Сегодня в сфере создания В2В продуктов происходит переосмысление взаимоотношений между заказчиком и исполнителем. И все чаще заказчика уже не устраивает роль подрядчика как простого исполнителя. Заказчик начинает выбирать исполнителя, который понимает и может продемонстрировать, как предлагаемая им система помогает достигать бизнес-результатов компании. Процессное мышление как раз и позволяет переходить к целостному видению того, как предлагаемое решение входит в цепочку создания ценности.
itWeek: Чем бы вы хотели завершить нашу беседу?
Д. Б.: Классическая автоматизация всем нам знакома и все еще широко практикуется. Но это уже пройденный этап в использовании информационных технологий. А вот для того, чтобы осуществлять реальную цифровую трансформацию бизнеса, нужно переходить от идеи автоматизации сложившихся рабочих мест к анализу цепочек создания заказчиком ценности для его клиента. Это может привести к совсем другой конфигурации процессов, часть которых выполняет машина. Особенно в банковской сфере или в управлении, где всю цепочку создания ценности можно перепроектировать уже целиком. Моделирование процессов, соединенное с компетенцией по созданию решений — это основа для реальной цифровой трансформации компаний. Да, это требует другого уровня мышления системных аналитиков. Но если говорить о моем личном опыте работы с аналитиками, то в целом гипотезу о том, что можно развивать их реальные компетенции и выводить на новые уровни мышления, я считаю доказанной.
itWeek: Спасибо за беседу.
