Оценка производительности решения

Записаться

Первой задачей области знания «оценка решения», является задача 8.1 Оценка производительности решения. Давайте посмотрим, в чем же состоит назначение этой задачи. Значение этой задачи - определить показатели производительности и собрать данные для оценки эффективности решения по отношению к той ценности которая она приносит.

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

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

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

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

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

• Какие бывают показатели производительности. Они могут быть либо количественными либо качественными. Если мы с вами обратимся к нашему примеру - внедрению нового финансового решения на базе ERP, то какие у нас могут быть здесь количественные показатели производительности? Предположим это может быть одновременный расчет какого-то большого количества данных, предположим, у нас раньше система не справлялась с большим объемом проводок. А сейчас, новая система должна с этим справляться - это количественный показатель. Предположим, у нас с вами долго собирались накопленные данные общим итогом за несколько лет и это доставляло нам неудобства. Это тоже количественный показатель. Допустим, раньше было полдня стало пять минут. Это вот типы количественных показателей, которые характеризуют необходимую нам производительность решения. Причем, эти показатели у каждой группы заинтересованных лиц могут быть свои. Например, показатели производительности для эксперта в какой-то области будут одни показатели производительности, а для конечного пользователя будут другие. Качественные показатели производительности не связаны с какими-то конкретными измеримыми вещами. Они могут быть связаны с впечатлением от обратной связи, когда люди говорят что решение очень удобно и им хорошо пользоваться. То есть они вроде как неизмеримые, но мы можем опереться на отзывы наших конечных пользователей или ключевых пользователей, на которые вы рассчитываете и трактовать это как качественные показатели производительности решения.
• Далее, после того как мы определились с каким-то перечнем этих показателей производительности, которые могут быть количественными или качественными, нам их необходимого валидировать. Этот процесс схожий с требованиями. Допустим, вы аналитик, у вас уже есть с предыдущего вашего опыта какой-то перечень показателей, вы часть их использовали и предлагаете заказчику. Он говорит: «это - нет спасибо, а вот это мне не нравится, это мне тоже не нравится, а вот это давайте рассмотрим». Это – валидация. В валидации могут участвовать заинтересованные стороны которые принимают решение о том работать ли дальше с данным показателем или нет. Валидация может быть не только со стороны заинтересованных сторон, она может быть со стороны каких-то вышестоящих показателей. То есть решение в компании не одно - у нас еще множество других информационных систем и других решений. У них тоже есть свои показатели производительности и наши показатели, которые мы еще будем применять, должны им не противоречить. Как вы знаете, в компаниях бывает так, что, когда проектируются система ключевых показателей эффективности - они должны быть сбалансированы. То есть, если мы с вами допустим одному отделу поставим одни ключевые показатели эффективности, а другому отделу противоречащие им, то начнется перетягивание одеяла между двумя этими отделам, поскольку мы поставили противоречащие критерии. Нам не нужна такая ситуация, нам нужно не противоречить существующим показателям производительности. Далее, следующий пункт — это собрать показатели. Это необходимо, потому что можно придумать очень разные интересные и хорошие показатели, но только собрать их будет очень трудно. Или это ручной сбор, который чреват ошибками, либо автоматически, который тоже затруднен, потому что необходимо определить как много, какие и по какому расписанию будем собирать с учетом сезонных циклов и так далее, это тоже необходимо продумать в рамках выполнения этой задачи по бизнес-анализу.

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

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

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

• Это может быть критерии приемки и оценки. С помощью этого метода мы определяем какой уровень производительности является для нас приемлемым с точки зрения приемки до ягодицы.
• Для расчета показателей производительности - что такое хорошо и что такое плохо, мы можем использовать бенчмаркинг, чтобы измерять наше решение с учетом рынка, что считается приемлемым, что считается хорошим.
• Мы с вами можем использовать интеллектуальный анализ данных data mining по-английски, когда мы собираем большие объем данных и анализируем и исходя из этого анализа определяем какие-то показатели.
• Еще мы можем с вами использовать фокус-группы, когда мы собираем группы наших пользователей, например, конечных пользователей или ключевых экспертов и с помощью этих вот фокус-групп выявляем какие-то показатели производительности.
• Безусловно это метрики и ключевые показатели эффективности. Здесь очень важный метод — это анализ не функциональных требований, напомню, что функциональные требования — это то, что система должна уметь делать, а не функциональный — это как она должна сделать, поэтому оценка производительности опирается во многом на анализ не функциональных требований, которые выдвигаются к системе.
• Возможен метод наблюдения. Чем он хорош - мы можем посмотреть, как работают с существующим решениями и с прототипом, который мы используем. Поскольку у нас есть уже какой-то прототип, мы можем дать людям попробовать – работайте. И, собственно говоря, посмотреть как люди работают. Это нам даст какие-то мысли о том какую метрику выбрать, чтобы оценить производительность.
• Самый основной метод, который можно использовать для решения данной задачи — это метод прототипирования, который широко сейчас используется в гибких подходах. Это когда вы выбираете какой-то период времени, когда регулярно делаете какие-то прототипы и показывайте их заказчику. Есть разные подходы по прототипированию. Прототип может быть одноразовый и эволюционный. Одноразовые вы можете набросать на бумаге дизайн вашего интерфейса и после этого выкинуть все и сейчас нарисовать какой-то новый дизайн, либо это эволюционный прототип, когда вы разрабатываете функциональное решение. С каждым прототипом функциональность нарастает и нарастает - это два разных подхода к прототипированию. Есть разные методики прототипирования. Например, с помощью бумаги и карандаша, или с помощью симуляции, когда мы можем, если стоит задача сократить время выполнения какого-то процесса в наших финансах, допустим, сократить цикл бюджетного планирования. Соответственно, говорим - нарисуем какой-то новый бизнес-процесс. Запускаем симуляцию его и показываем заказчику. Вот это новый процесс, который при определенных условиях будет выполняться значительно быстрее, вот такой может использоваться метод.

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