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