Какие измерения вы используете для улучшения своих процессов?[закрыто]

Question

Первоначально этот вопрос звучал так: «Какие ключевые показатели эффективности вы используете в организации, занимающейся разработкой программного обеспечения».К сожалению, похоже, что КПЭ это слово из четырех букв, и сразу можно предположить, что KPI всегда используются неправильно (может быть, так и есть?).

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

Учитывая все это, как узнать, оказывают ли усовершенствования вашего процесса положительный эффект?Если это КПЭ, или [Цели SMART](http://en.wikipedia.org/wiki/SMART_(project_management) укажите отдельные или группы ключевых показателей эффективности/целей SMART, которые, по вашему мнению, являются эффективными.Если это какой-то другой механизм, пожалуйста, объясните, что это такое.Наконец, я думаю, если вы не думаете, что улучшение процессов — это полезная вещь, я думаю, вы тоже можете это объяснить.

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

Уточняющие примечания:

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

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

А процесс может быть что угодно;схватка, agile, экстрим, водопад, специальный.Вопрос не в том, какой процесс лучше всего подходит для определенных типов разработки программного обеспечения, а в том, как улучшить этот процесс с течением времени.

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

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

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

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

Этот вопрос не имеет ничего общего с исходные строки кода!В частности, меня не интересует измерение производительности программистов, особенно с точки зрения количества SLOC или количества исправленных ошибок, или любых других наивных измерений.Меня интересует более высокий уровень, с помощью которого команда или отдельный человек измеряет свое улучшение.Я не заинтересован в использовании единого KPI для измерения чьей-либо производительности.я являюсь заинтересован в использовании ряда KPI для измерения и улучшения процессов разработки программного обеспечения моей команды.

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

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

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

Answer 1

Безусловно, лучшим показателем является «доставленная и принятая протестированная функциональность».В мире Agile мы обычно измеряем «функциональность» с точки зрения «пользовательских историй», но она может быть в любой удобной форме, при условии, что она измеряет фактическую предоставленную и протестированную функциональность, приемлемую для клиента.

Другие обычные показатели, такие как SLOC, SLOC/трудозатраты на персонал и т. д., терпят неудачу из-за Первого закона менеджмента Чарли, который гласит:

Люди будут доставлять все, что они будут вознаграждены, чтобы доставить.

Настройте свои измерения как SLOC, и вы получите много SLOC.Используйте SLOC/час, вы получите много SLOC/ht.Дайте им бонусы за сверхурочную работу, и вы получите много сверхурочных.

Да, и помните также корреляцию:

То, что люди доставляют, это то, что, по их мнению, будет полезно доставить.

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

Answer 2

Когда я слышу ключевой показатель эффективности, я немного волнуюсь, потому что обычно следующее, что нужно сделать, — это связать производительность с вознаграждением, и тогда вы можете очень быстро застрять.Мне всегда напоминают о фирме-разработчике программного обеспечения, которая приняла решение о системе вознаграждений за исправление ошибок: тестировщики будут вознаграждаться за обнаружение ошибок, а разработчики - за исправление ошибок.Разработка остановилась, поскольку вокруг мгновенного создания, обнаружения и исправления ошибок сформировался черный рынок.

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

• Продажи. Соответствует ли ваш продукт требованиям клиентов?Вы можете измерить это с точки зрения соотношения презентаций программного обеспечения и продаж или посещений страницы покупки вашего веб-сайта с фактическими покупками.
• Качество. Является ли ваше программное обеспечение понятным и надежным?Сколько звонков в службу поддержки вы получаете в день на одного клиента?Вопросы о том, как что-то сделать или ошибки?
• Удовлетворенность клиентов. Насколько клиенты удовлетворены вашим продуктом?Опросите своих клиентов и выясните, что вы могли бы сделать, чтобы повысить их удовлетворенность, а затем опросите их снова позже, чтобы узнать, улучшились ли вы.(Не раздражайте своих клиентов, задавая много вопросов или делая это слишком часто)

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

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

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

Обновлять попытаться ответить на пересмотренный вопрос

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

Возьмем в качестве примера профессию, где KPI широко используются, — юристов.Юристы для оценки используют такие ключевые показатели эффективности, как:среднее количество отработанных часов в день;часы оплачиваются в месяц;возраст реестра дебиторов;средний возраст неоплачиваемой работы;процент списанных комиссий;и так далее.Здесь следует заметить тенденцию — все эти KPI связаны с желанием (или нежеланием) клиентов платить за оказанные услуги.Это окончательный арбитр успеха, и именно поэтому я предложил (выше) некоторые способы использования этого типа измерения в качестве ключевых показателей эффективности для вашего бизнеса по разработке программного обеспечения.

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

«Доллары, выплачиваемые клиентами», имеют фиксированное значение из года в год — произвольные показатели, такие как «ошибки в программном обеспечении», «своевременность выпуска» и «гибкость», не имеют фиксированного значения, и увеличение KPI может не иметь прямого значения. отношение к базовому значению, которое должно измеряться с помощью KPI, например, «больше ошибок означает более низкое качество».

Например, после Колумбийская катастрофа, Помню, следственная группа выдвинула несколько сотен рекомендаций и объектов для расследования.Означали ли эти недавно обнаруженные «ошибки» качество космического корабля внезапно ухудшилось?На самом деле, после расследования космический шаттл стал более качественным.Таким образом, KPI по ошибкам может быть легко искажен обширным сеансом контроля качества, а большее количество сообщений об ошибках может фактически означать, что ваше программное обеспечение имеет более высокое качество.

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

Что касается гибкости, я даже не могу предположить, как можно измерить что-то столь неосязаемое.

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

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

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

Answer 3

Бенно, я отвечаю на твой комментарий, но для ответа не хватило символов.

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

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

Еще одна вещь, которой следует опасаться, это то, что если люди узнают, что вы что-то измеряете, они будут бояться, что измеряется их личная производительность, и поэтому будут обманывать систему, чтобы получить хорошие результаты.Часто бывает лучше, если вы сможете провести измерения на основе какой-либо уже существующей системы (у нас есть система, которая управляет запросами на изменения программного обеспечения, мы могли бы запросить базу данных, чтобы исторически узнать, сколько запросов пропустило крайний срок, сколько мы повторно открыли после того, как были закрыты или связаны с прошлыми запросами и т. д., какова разница во времени между завершением разработки и переводом кода в производство и т. д.являются).Возможно, вам также придется рассмотреть возможность устранения серьезных выбросов, особенно если время охватывает период времени как старой, так и новой системы.Например, у нас есть один запрос, который находится в Qa более 100 дней не потому, что он плохой, а потому, что у QA есть проблема с доступностью, и этот запрос имеет самый низкий приоритет, поэтому его продолжают переводить на работу с более высоким приоритетом.Это время не будет иметь ценности при измерении улучшения времени, поскольку фактор, делающий время таким длинным, не является тем процессом, который вы пытаетесь исправить.Если вы построите график данных, вы легко увидите выбросы, которые, возможно, потребуется исключить.

Answer 4

Хорошим началом будет базирование ваших KPI на стоимости, качестве и графике.Подумайте, каковы атрибуты каждого из тех, кого вы хотите измерить.

Была бы полезна возможность разделить каждый из этих показателей, чтобы показать стоимость ошибок: большое количество усилий по исправлению ошибок на поздних стадиях проекта означает провал затрат/графика.Возможность определить, какие части кодовой базы содержат ошибки, может помочь в проведении дополнительного тестирования и возможной переписывании кода — обычно 80% ошибок происходят из 20% кода.Знание того, где это находится, позволит вашей команде лучше сосредоточиться.

РЕДАКТИРОВАТЬ:Посмотрите на такие показатели, как стоимость качества (CoQ) и стоимость низкого качества (CoPQ).

Такие показатели, как производительность, всегда трудно измерить количественно — например, использование LOC/day приводит к спорам о том, что именно представляет собой строка кода?Это также может привести к глупому форматированию кода для «повышения» производительности, если разработчики не понимают, почему эти вещи отслеживаются, или воспринимают их как личные измерения.Даже если LOC/день не измеряется на уровне разработчиков, вы все равно можете получить командное соперничество, ведущее к одному и тому же результату.

РЕДАКТИРОВАТЬ:Несколько хороших дискуссий можно найти на странице Стива МакКоннелла. Конструкс Веб-сайт.[Да, это Стив МакКоннелл из Code Complete]

Answer 5

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

Да, вам определенно все еще нужен кто-то, кто смотрит на макроуровне.Если вы посмотрите на такую ​​организацию, как Toyota, у них есть главный инженер, который находится на грани между бизнесом и производством (хорошее объяснение см. в статье Скотта Беллвара). Сообщение блога).В нашей организации есть кто-то похожий — мой босс был одним из первых разработчиков нашего продукта почти 20 лет назад и по-прежнему активно занимается техническими вопросами, но также вкладывает значительные средства в работу с клиентами.Моя работа также состоит в том, чтобы смотреть на команды в целом и предлагать улучшения.

Для измерения мы сначала убеждаемся, что любые улучшения, к которым мы стремимся, действительно могут быть изменены нашими командами, а затем используем что-то вроде УМНЫЕ цели чтобы любые улучшения были измеримы.У нас есть Большая, видимая стена на котором мы размещаем заметки из ретроспективы.Здесь мы также проводим ежедневные стендапы, что позволяет нам сосредоточиться на том, что происходит.

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

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

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

Answer 6

Я профессионально занимался улучшением процессов в течение 14 лет.Вот мой совет: перестаньте пытаться количественно оценить и начните разговаривать с людьми.Измерения хорошо подходят для решения конкретной проблемы (как только вы поймете проблему, у вас будет лучшее представление о том, что измерять), а также для повторяющихся процессов, таких как производство.Ваши люди точно знают, где находятся проблемные области, так же как и ваши клиенты и пользователи (с совершенно другой точки зрения).Блок-схема (используйте символы промышленного проектирования, а не символы компьютерного программирования) реального процесса для областей, где есть проблемы (это не то, что мы притворяемся, вам нужно будет наблюдать, а также задавать вопросы).Как только вы увидите весь поток процесса, обратите внимание на задержки, области, где работа дублируется, области, где есть ненужный процесс (обычно из-за добавления дополнительных шагов в процесс для учета человеческих ошибок, создавая тем самым гораздо больше потенциальных областей для человеческого фактора). ошибка).Задайте себе вопрос о необходимости каждого шага и о том, есть ли лучший способ сделать каждый шаг.Проверьте потенциальные изменения и посмотрите, действительно ли они являются улучшением (слишком часто они ухудшают ситуацию, а не улучшают ее).Ни при каких обстоятельствах не разговаривайте с менеджерами только тогда, когда вы ощущаете проблемы или составляете блок-схемы.Вы не получите истинной картины и, таким образом, решите не ту проблему.

Answer 7

Понимание карт потерь и потоков создания ценности покажет вам, где вам необходимо внести улучшения, и на основе этих знаний вы узнаете, что вам нужно измерить.Здесь применимы принципы Lean и Kanban.Понимание потерь и их влияния на производство программного обеспечения направит вас на конкретный путь к улучшению, который неизбежно специфичен для вашей организации.Вы не можете использовать шаблонный подход.Прочтите (или послушайте) «Цель» и «Бережливое мышление», чтобы узнать больше об этом действительно удивительном и поучительном взгляде на то, что не так и как это исправить.

Answer 8

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

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

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

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

Если последнее, выберите скорость.Конечно, при условии, что вы используете разработку через тестирование (TDD).

РЕДАКТИРОВАТЬ:так что это первое.Ну, вот почему вам, вероятно, не повезло:

Предположим, вы решили, что «качество» лучше всего оценивать количественно, измеряя количество ошибок, о которых сообщили клиенты, в качестве KPI постобработки.Предположим, вы используете TDD, и ваша команда выпускает Продукт №1 за 6 месяцев, а через 6 месяцев работы вы обнаруживаете, что у вас есть 10 ошибок, о которых сообщили клиенты.Итак, что именно вы собираетесь сделать, чтобы улучшить свой процесс?Тестировать больше?Специально протестировать больше вещей, например, причины обнаруженных ошибок?Мне кажется, вы бы уже тестировали, и при обнаружении ошибок — заказчиком или нет — вы добавляете регрессионный тест на конкретную ошибку и дополнительные юнит-тесты, чтобы убедиться, что подобных ошибок больше нет.Другими словами, ваш ответ на улучшение после процесса не будет отличаться от вашего ответа на улучшение в процессе, поэтому этот KPI на самом деле не окажет существенной помощи в улучшении вашего процесса.Дело в том, что способ улучшения вашего процесса остается неизменным независимо от того, обнаружены ли ошибки через 6 месяцев после выпуска или через два дня после начала написания кода.Таким образом, хотя это может быть блестящий KPI, который можно повесить на стену менеджера или в информационный бюллетень отдела, на самом деле он не изменит ваши механизмы улучшения процессов.(И остерегайтесь придавать слишком большое значение этому KPI, поскольку на него могут сильно влиять факторы, находящиеся вне вашего контроля!).Суммируя, знание количества ошибок не поможет вам улучшить.

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

Предположим, что количество возвратов/возвратов клиентов является вашим ключевым показателем эффективности для «качества». Если это число равно 5, о чем это вам говорит?Конкретными причинами, по которым клиенты запросили возврат средств, могут быть некоторые признаки проблем с качеством («слишком медленно», «не взаимодействует с системой XYZ» и т. д.), но просто число о таких инцидентах вам ничего не скажут.Отклонение от ожидаемого процента доходности может сказать вам, улучшилось ли качество, но опять же. число не поможет вам улучшиться.Вам нужно больше информации, чем может дать номер.

Итак, какое измерение будет подходящим для «своевременности выпусков»?Количество дней сдвига даты отгрузки?Процент перерасхода по первоначальным оценкам? Это не имеет значения, потому что снова цифры не помогут вам стать лучше.

Если вы можете измерить «производительность» после того, как продукт готов, то, вероятно, вы сможете измерить ее и во время разработки продукта (например,разница в том, что производительность, меньшая, чем ожидалось во время разработки, может быть повышена немедленно, в то время как общий показатель производительности, измеренный после завершения разработки, слишком грубый, слишком усредненный, чтобы его можно было использовать.Можно только догадываться, почему спустя 6 месяцев она оказалась ниже ожидаемой...

Я понятия не имею, как можно измерить «гибкость», это звучит как маркетинговый жаргон ;-)

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

Answer 9

Вы можете получить много идей о KPI и примерах Панели мониторинга в http://www.dashboardzone.com

Он имеет KPI по отраслям и функциональным областям.