Аналитик, проанализируй мне эту задачу - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.
Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться.
ИТ-аналитик в статье - это роль, которую может выполнять выделенный сотрудник, а может и разработчик или любой другой сотрудник.
Понятия потребность и требование
В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).
Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.
Бизнес обращается к нам с какой-то проблемой, болью, которую он не знает как решить и наша задача - показать ему что делать.
Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.
Выявление потребностей и целеполагание
Пациент приходит к доктору и требует Выпишите мне аспирин, срочно!!!.
Требование = Выписать аспирин. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.
Требование (requirement) - это некоторый образ или свойство результата, который кто-то у кого-то требует. Выпишите аспирин, Программа должна делать это - это требование. Термин не самый удачный в русском языке, он плохо стыкуется с бытовым толкованием, что запутывает заказчика и аналитика.
Требование лежит в области решения (solution). Поесть в ресторане, Приготовь еду - это требования.
Что делает хороший аналитик ? Выявляет потребности и анализирует их, определяя влияние на бизнес (почему, в чем причина, как часто, какой ущерб для бизнеса, в каком проценте случаев, в какой географии, для каких клиентов, ..). Понимание потребности дает понимание что делать, какое решение нужно, какое требование к решению важно.
Поэтому аналитик выявляет потребности и проектирует решение (требования к решению).
В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.
-
Обеспечить функциональность
-
Качественную работу
-
Скорость/Производительность
-
Безопасность
-
Низкие издержки
-
И т.п.
Разрыв ожиданий и реальности атрибутов качества создает проблему, которую нужно решить, и для этого нужны какие-то изменения. Устранение разрыва будет целью (goal) будущего изменения.
Внедрение или улучшение ИТ системы нужно для улучшения атрибутов качества бизнес-процесса, иначе оно не приносит пользы и поэтому бессмысленно.
Выявление контекста и ограничений
Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее решениями (decision).
Разгрузить грузовик - это сложно? Неясно, так как неясен контекст.
К примеру, Разгрузи грузовик в минус 40, на дне озера и Разгрузи грузовик в плюс 25, на асфальте выглядят как совершенно разные задачи.
Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика.
Выявление контекста - сфокусировано на области, где проявляют себя потребности. Нет смысла начинать решение задачи с описания текущих процессов, если не сформулировано цели (потребности, боли) изменений. Процессов и деталей этих процессов слишком много, их изучение само по себе без цели не имеет смысла и окончания.
Перед проектированием будущего изменения часто нужно выявить желаемые сроки внедрения. Возможны разные варианты:
-
Сделать к черной пятнице,
-
Сделать, потому что каждый день мы что то теряем,
-
Сделать, иначе с какого-то момента мы будем каждый день что-то терять.
Таким образом выявляются ожидания/ограничения по срокам.
Не всегда все нужно делать монументально, часто бизнес не уверен в будущих выгодах. В этом случае стоит сделать более быстрое/менее качественное решение, чтобы проверить гипотезу. Также иногда лучше сделать менее качественно, но более быстро, даже если это заплатка или костыль. Нужно выявить ожидания/ограничения по качеству.
Часто заказчики выбирают решение с минимальной стоимостью внедрения/владения в рамках заданных сроков и качества. Иногда ограничена стоимость и нужно подобрать оптимальное сочетание сроков/качества.
В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).
Кроме того, область решений (solution) ограничена еще:
-
Ограничениями по ресурсам
-
Требованиями удобства пользователей
-
Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса
-
Выбором подрядчиков и правилами привлечения новых
-
Правилами работы с подрядчиками
-
Требованиями безопасности и распространения информации
-
Требованиями регуляторов
-
И т.д.
Не зная ограничения, нельзя спроектировать решение с их учетом.
В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.
Проектирование решения
Аналитик создает непротиворечивые, полные, проверяемые модели, отражающие какой-то срез или проекцию будущей системы для согласования с стейкхолдерами и для принятия управленческих решений (делаем так/изменяем/не делаем). Наиболее полная модель - это реализованная система, но часто достаточно меньших усилий для получения нужных ответов на вопросы.
Моделей системы может быть несколько (и довольно много), но типовые это
-
Функциональная модель, отвечающая на вопрос как это работает, функционирует, обеспечивает функцию.
-
Конструктивная модель, отвечающая на вопрос как это сконструировано, из каких частей состоит.
-
Географическая модель, отвечающая на вопрос где это работает или где расположены части делается совместно на основе предыдущих двух.
-
Финансовая модель, отвечающая на вопрос сколько стоит создание, поддержка, вывод из эксплуатации решения, в какие сроки и за счет чего отобьются вложенные инвестиции, также часто собрать данные - это работа аналитика. Эта модель основная для принятия управленческих решений опирается на конструктивную и географическую модели.
Потребностей может быть много, решение, которое закрывает все потребности часто оказывается за рамками выявленных ограничений. К тому же часто нет уверенности, что закрытие потребностей приведет к ожидаемому бизнес-эффекту. Это толкает руководство к итерационной разработке с получением работающих решений на ранних этапах. Для проектирования таких решений какие-то потребности останутся не закрыты или закрыты не полностью.
Аналитик решает задачу по проектированию такого решения, которое закрывает потребности по правилу Парето, 20% усилий должны принести 80% бизнес-результата, где усилия берутся из треугольника (цена-качество-сроки) в рамках выявленных ограничений, а результат - это оценка улучшения атрибутов качества бизнес-процесса.
Иными словами в каждой следующей итерации должна быть создана система, которая приносит максимум пользы бизнесу, но при этом которая может быть создана в небольшие сроки (с учетом того, что некоторые пропасти не перешагнуть в два шага).
ИТ аналитику в поиске помогают
-
Знание того, как ИТ решают задачи по улучшению процессов,
-
Знание того, какие ключевые свойства потребностей влекут разные способы реализации,
-
Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,
-
Знание предметной области,
-
Знание процессного управления и процессов управления изменениями,
-
Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,
-
Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.
-
Знание того, как ИТ решают задачи по улучшению процессов,
-
Знание того, какие ключевые свойства потребностей влекут разные способы реализации,
-
Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,
-
Знание предметной области,
-
Знание процессного управления и процессов управления изменениями,
-
Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,
-
Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.
-
Знание того, как ИТ решают задачи по улучшению процессов,
-
Знание того, какие ключевые свойства потребностей влекут разные способы реализации,
-
Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,
-
Знание предметной области,
-
Знание процессного управления и процессов управления изменениями,
-
Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,
-
Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.
Исправление ошибок системы на стадии проектирования дешевле, чем после его реализации. И поскольку любой аналитик иногда да ошибается, то решение, которое он создал стоит проверять.
Наибольший эффект контроля качества достигается с помощью формализации условий задачи (потребности, цели, контекст, ограничения) и решения задачи (модели будущей системы). Без условий задачи, решение проверить невозможно.
Дайте мне аспирин А это вылечит вашу боль?(неизвестно, если причина боли не диагностирована)
Внедрение решения
При проектировании на первых итерациях получается не полнофункциональная ИТ-система. При создании ИТ системы с нуля, как правило, закрывается главная дорога, а исключения и боковые ветви остаются за рамками создаваемого ИТ решения. При внедрении готового решения за рамками остаются процессы, которые туда не ложатся. Для внедрения ИТ-системы нужно выработать подходы, что делать с этими случаями. Либо менять процессы, либо закрывать потребности с помощью более простых и универсальных решений типа Excel (Googledocs, ) и регламентов.
Зачастую аналитик создает эти временные подпорки и формирует требования на изменения регламентов так, чтобы внедрение не привело к серьезным сбоям процесса.
Также зачастую аналитик готовит данные либо формирует требования по их преобразованиям.
Если можно внедрить систему в географически выделенных подразделениях, то аналитик прорабатывает то, каким образом будут взаимодействовать старая и новая система совместно, обеспечивая один процесс.
Когда все готово, аналитик проводит обучения ключевых пользователей и сопровождает внедрение.
Активное участие аналитика во внедрении необходимо, чтобы аналитик получил обьективную обратную связь по спроектированному решению, нашел ошибки в методиках проектирования и развивался.
Резюме
Работа аналитика это превращение проблем в задачи, при котором характерны этапы:
-
Выявление потребностей и целеполагание,
-
Выявление контекста и ограничений,
-
Проектирование решения,
-
Внедрение решения.
Опыт проектирования и внедрения решения необходим для грамотного выявления потребностей, контекста и ограничений. Без опыта неясно что из потребностей в каких ограничениях возможно закрыть автоматизацией. Без опыта выявления потребностей и ограничений можно спроектировать неверное решение.
И тем не менее, самая ценная часть - это проектирование решения. Первые три пункта может сделать грамотный заказчик. Последнее - ключевой пользователь. И поэтому лучшее название этой роли - аналитик-проектировщик.
Основная ценность работы аналитика-проектировщика для бизнеса состоит в поиске и создании непротиворечивых проверяемых моделей решения, закрывающего потребности по правилу Парето 80 на 20, имея как фокус проявленную выгоду от внедрения с учетом выявленных ограничений.
Для этого аналитик-проектировщик выявляет потребности, цели изменения, проектирует и согласовывает требования, отсекая часть требований на последующую автоматизацию и создавая модели решения, отвечающие этим требованиям.
P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье