“Аналитик, проанализируй мне эту задачу” - говорит бизнес-заказчик. Что он имеет в виду? Анализ - это всего лишь  метод исследования, характеризующийся выделением и изучением отдельных частей объектов исследования (по википедии), но бизнес в своих словах подразумевает нечто большее, чем просто анализ.

Что делает ИТ-аналитик и в чем ценность его работы для бизнеса? Пробуем разобраться. 

ИТ-аналитик в статье - это роль, которую может выполнять выделенный сотрудник, а может и разработчик или любой другой сотрудник.

Понятия потребность и требование

В анализе и проектировании аналитик работает с двумя областями. Область потребностей = нужд (needs) и область решений (solution).

Закрыть одну потребность можно разными способами. Каждый способ имеет разные атрибуты качества. Поесть в ресторане быстрее и вкуснее, но купить продукты в магазине, приготовить и съесть что-нибудь дома дешевле.

Бизнес обращается к нам с какой-то проблемой, болью, которую он не знает как решить и наша задача - показать ему что делать. 

Задача аналитика в поиске и выборе наиболее подходящего для заказчика способа решения (solution) его боли и проблемы.

Выявление потребностей и целеполагание

Пациент приходит к доктору и требует “Выпишите мне аспирин, срочно!!!”.

Требование = “Выписать аспирин”. Что делает доктор в данном случае? Плохой доктор даст аспирин. Хороший доктор будет выявлять причины проблемы и лечить их.

Требование (requirement) - это некоторый образ или свойство результата, который кто-то у кого-то требует. “Выпишите аспирин”, “Программа должна делать это” - это требование. Термин не самый удачный в русском языке, он плохо стыкуется с бытовым толкованием, что запутывает заказчика и аналитика.

Требование лежит в области решения (solution). “Поесть в ресторане”, “Приготовь еду” - это требования.

Что делает хороший аналитик ? Выявляет потребности и анализирует их, определяя влияние на бизнес (почему, в чем причина, как часто, какой ущерб для бизнеса, в каком проценте случаев, в какой географии, для каких клиентов, ..). Понимание потребности дает понимание что делать, какое решение нужно, какое требование к решению важно.

Поэтому аналитик выявляет потребности и проектирует решение (требования к решению). 

В разное время разные бизнесы стремятся к оптимизации разных атрибутов качества своих систем и процессов.

1. Обеспечить функциональность

2. Качественную работу

3. Скорость/Производительность

4. Безопасность

5. Низкие издержки

6. И т.п.

Разрыв ожиданий и реальности атрибутов качества создает проблему, которую нужно решить, и для этого нужны какие-то изменения. Устранение разрыва будет целью (goal) будущего изменения.

Внедрение или улучшение ИТ системы нужно для улучшения атрибутов качества бизнес-процесса, иначе оно не приносит пользы и поэтому бессмысленно.

Выявление контекста и ограничений

Разумеется заказчик находится в какой-то ситуации и он ограничен принятыми ранее  решениями (decision).

“Разгрузить грузовик” - это сложно? Неясно, так как неясен контекст.

К примеру, “Разгрузи грузовик в минус 40, на дне озера” и “Разгрузи грузовик в плюс 25, на асфальте” выглядят как совершенно разные задачи.

Для проектирования модели нужно разобраться в контексте того, как полученное решение (solution) будет использоваться, в каком процессе и для чего. Какая ситуация у заказчика. 

Выявление контекста - сфокусировано на области, где проявляют себя потребности. Нет смысла начинать решение задачи с “описания текущих процессов”, если не сформулировано цели (потребности, боли) изменений. Процессов и деталей этих процессов слишком много, их изучение само по себе без цели не имеет смысла и окончания.

Перед проектированием будущего изменения часто нужно выявить желаемые сроки внедрения. Возможны разные варианты:

1. Сделать к “черной пятнице”, 

2. Сделать, потому что каждый день мы что то теряем, 

3. Сделать, иначе с какого-то момента мы будем каждый день что-то терять.

Таким образом выявляются ожидания/ограничения по срокам.

Не всегда все нужно делать монументально, часто бизнес не уверен в будущих выгодах. В этом случае стоит сделать более быстрое/менее качественное решение, чтобы проверить гипотезу. Также иногда лучше сделать менее качественно, но более быстро, даже если это “заплатка” или “костыль”. Нужно выявить ожидания/ограничения по качеству.

Часто заказчики выбирают решение с минимальной стоимостью внедрения/владения в рамках заданных сроков и качества. Иногда ограничена стоимость и нужно подобрать оптимальное сочетание сроков/качества. 

В итоге, складывается понимание ограничений на проектный треугольник (стоимость/сроки/качество).

Кроме того, область решений (solution) ограничена еще:

1. Ограничениями по ресурсам

2. Требованиями удобства пользователей

3. Решениями по существующему ИТ-ландшафту и уровню ИТ сервиса

4. Выбором подрядчиков и правилами привлечения новых

5. Правилами работы с подрядчиками

6. Требованиями безопасности и распространения информации

7. Требованиями регуляторов

8. И т.д.

Не зная ограничения, нельзя спроектировать решение с их учетом.

В случае слишком жестких ограничений решения может и не найтись. Тогда ограничения заменяются функциями штрафа и аналитик ищет наименее болезненное решение.

Проектирование требований

Выявленные потребности в выявленном контексте дают возможность начать проектировать будущее решение.

При проектировании удобно в первую очередь создать набор атомарных требований, описывающий какой-то аспект будущего решения и уже после этого приступать к моделированию.

Например, я решил пожарить картошку, чтобы поесть. Для этого мне нужно как-то ее очистить и помыть, как-то нарезать и в чем-то ее пожарить. Мне нужен инструмент для жарки картошки - это потребность.

Создаем требования на инструменты. Я требую инструмент с нагреваемой емкостью. Имея инструмент (а также масло и соль) я могу пожарить картошку.

Какая емкость? Какого объема? Неясно, требований не достаточно.

Дополняем потребность из контекста - мне нужно готовить в среднем на два человека. Требование - емкость объемом один литр (такие требования иногда называют нефункциональными).

Каким образом будет подаваться энергия в инструмент? Ограничением будет использование только существующих источников энергии. У нас дома электричество, есть кухонная плита, но газа нет. С учетом этого появляется требование - использование электричества или кухонной плиты, как источника энергии.

Проектирование решения

Аналитик создает непротиворечивые, полные, проверяемые модели, отражающие какой-то срез или “проекцию” будущей системы для согласования с стейкхолдерами и для принятия управленческих решений (делаем так/изменяем/не делаем). Наиболее полная модель - это реализованная система, но часто достаточно меньших усилий для получения нужных ответов на вопросы.

Например, модель системы из предыдущего примера это электрическая фритюрница.

Моделей системы может быть несколько (и довольно много), но типовые это

1. Функциональная модель, отвечающая на вопрос “как это работает, функционирует, обеспечивает функцию”. 

2. Конструктивная модель, отвечающая на вопрос “как это сконструировано, из каких частей состоит”. 

3. Географическая модель, отвечающая на вопрос “где это работает” или “где расположены части” делается совместно на основе предыдущих двух.

4. Финансовая модель, отвечающая на вопрос “сколько стоит создание, поддержка, вывод из эксплуатации решения, в какие сроки и за счет чего отобьются вложенные инвестиции”, также часто собрать данные - это работа аналитика. Эта модель основная для принятия управленческих решений опирается на конструктивную и географическую модели.

Потребностей может быть много, решение, которое закрывает все потребности часто оказывается за рамками выявленных ограничений. К тому же часто нет уверенности, что закрытие потребностей приведет к ожидаемому бизнес-эффекту. Это толкает руководство к итерационной разработке с получением работающих решений на ранних этапах. Для проектирования таких решений нужно признать, что какие-то потребности останутся не закрыты или закрыты не полностью.

В итерационной разработке, в каждой следующей итерации должна быть создана система, которая приносит максимум пользы бизнесу, но при этом которая может быть создана в небольшие сроки (с учетом того, что некоторые пропасти не перешагнуть в два шага).

Аналитик решает задачу по проектированию такого решения, которое закрывает потребности по правилу Парето, 20% усилий должны принести 80% бизнес-результата, где усилия берутся из треугольника (цена-качество-сроки) в рамках выявленных ограничений, а результат - это оценка улучшения атрибутов качества бизнес-процесса. 

В нашем примере альтернативная модель - инструмент это сковородка, которая разогревается с помощью кухонной плиты. Оно требует больше времени на готовку, зато обеспечивающая достаточное качество и оно значительно дешевле.

ИТ аналитику в поиске помогают

• Знание того, как ИТ решают задачи по улучшению процессов, 

• Знание того, какие ключевые свойства потребностей влекут разные способы реализации,

• Знание готовых ИТ решений, решающих задачу полностью или частично или умения быстро их находить и выбирать оптимальное,

• Знание предметной области,

• Знание процессного управления и процессов управления изменениями,

• Понимание трудоемкости, стоимости и сложности решения широкого спектра ИТ задач,

• Ну и разумеется, эксперты, партнеры по интеграции, смежники, вендоры ИТ решений и разработчики.

Исправление ошибок системы на стадии проектирования дешевле, чем после его реализации. И поскольку любой аналитик иногда да ошибается, то решение, которое он создал стоит проверять. 

Наибольший эффект контроля качества достигается с помощью формализации условий задачи (потребности, цели, контекст, ограничения) и решения задачи (модели будущей системы). Без условий задачи, решение проверить невозможно.

“Дайте мне аспирин” 
“А это вылечит вашу боль?”
(неизвестно, если причина боли не диагностирована)

Внедрение решения

При проектировании на первых итерациях получается не полнофункциональная ИТ-система. При создании ИТ системы с нуля, как правило, закрывается главная дорога, а исключения и боковые ветви остаются за рамками создаваемого ИТ решения. При внедрении готового решения за рамками остаются процессы, которые туда не ложатся. Для внедрения ИТ-системы нужно выработать подходы, что делать с этими случаями. Либо менять процессы, либо закрывать потребности с помощью более простых и универсальных решений типа Excel (Googledocs, …) и регламентов.

Зачастую аналитик создает эти временные подпорки и формирует требования на изменения регламентов так, чтобы внедрение не привело к серьезным сбоям процесса.

Также зачастую аналитик готовит данные либо формирует требования по их преобразованиям.

Если можно внедрить систему в географически выделенных подразделениях, то аналитик прорабатывает то, каким образом будут взаимодействовать старая и новая система совместно, обеспечивая один процесс.

Когда все готово, аналитик проводит обучения ключевых пользователей и сопровождает внедрение.

Активное участие аналитика во внедрении необходимо, чтобы аналитик получил обьективную обратную связь по спроектированному решению, нашел ошибки в методиках проектирования и развивался.

Резюме

Работа аналитика это превращение проблем в задачи, при котором характерны этапы:

1. Выявление потребностей и целеполагание,

2. Выявление контекста и ограничений,

3. Проектирование требований,

4. Проектирование решения,

5. Внедрение решения.

Опыт проектирования и внедрения решения необходим для грамотного выявления потребностей, контекста и ограничений. Без опыта неясно что из потребностей в каких ограничениях возможно закрыть автоматизацией. Без опыта выявления потребностей и ограничений можно спроектировать неверное решение.

И тем не менее, самая ценная часть - это проектирование требований и моделей решения (еще говорят, инженерия требований и моделей решения). Первые три пункта может сделать грамотный заказчик. Последнее - ключевой пользователь. И поэтому лучшее название этой роли - аналитик-проектировщик (более строго аналитик-инженер, но термин инженер, увы, сильно искажен). 

Основная ценность работы аналитика-проектировщика для бизнеса состоит в поиске и создании непротиворечивых проверяемых моделей решения, закрывающего потребности по правилу Парето 80 на 20, имея как фокус проявленную выгоду от внедрения с учетом выявленных ограничений.

Для этого аналитик-проектировщик выявляет потребности, цели изменения, проектирует и согласовывает требования, отсекая часть требований на последующую автоматизацию и создавая модели решения, отвечающие этим требованиям.

P.S. Спасибо участникам КиФБ за отзывы и корректировки к статье, а так же отдельное спасибо Денису Бескову и Анатолию Левенчуку за то, что помогли взглянуть на проблему системно