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

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

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

Править: Взгляд на меры как Стоимость качества (CoQ) и Стоимость низкого качества (CoPQ).

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

Править: Существуют некоторые хорошие обсуждения, которые будут найдены на веб-сайте Steve McConnell Construx. [Да, это - Steve McConnell Кода Полная известность]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, после аварии Колумбии, я вспоминаю, что следственная группа придумала несколько сотен рекомендаций и объектов, которые будут исследованы. Эти недавно обнаруженные "ошибки" означали, что шаттл внезапно имел намного меньше качества? На самом деле после расследования шаттл имел больше качества. Таким образом, KPI вокруг ошибок может легко быть искажен обширной сессией QA, и больше сообщенных ошибок может на самом деле означать, что Ваше программное обеспечение имеет более высокое качество.

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

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

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

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

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

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

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

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

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

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

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

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

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

Можно получить партию идей о KPIs и Примерах Панелей инструментов по http://www.dashboardzone.com

Это имеет kpis промышленностью и функциональными областями.

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

(См., что Панели инструментов для Управления для большего количества болтовни об этой подтеме. Протест: Я - автор болтающей статьи.)

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

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

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

Править: таким образом, это - первый. Ну, вот то, почему Вам, вероятно, не повезло:

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

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

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

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

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

Я понятия не имею, как можно было бы измерить "гибкость", которая походит на маркетинговый жаргон ;-)

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